* 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: 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: [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
* [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: [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
* 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: 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: [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: 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: [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: [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
* [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
* [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
* 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
* [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: [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
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Hin-Tak Leung @ 2009-08-26 13:33 UTC (permalink / raw)
To: Hin-Tak Leung, Johannes Berg
Cc: Larry Finger, Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <1251277063.10667.10.camel@johannes.local>
--- On Wed, 26/8/09, Johannes Berg <johannes@sipsolutions.net> 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, I am. I mentioned this and did wonder if the _backport/ part in /sys/class is important.
Hin-Tak
^ permalink raw reply
* Re: [PATCH] ath5k: fix print on warning on ath5k_hw_to_driver_rix()
From: Bob Copeland @ 2009-08-26 14:08 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <20090825233827.GA10998@mosca>
On Tue, Aug 25, 2009 at 7:38 PM, Luis R. Rodriguez<lrodriguez@atheros.com>
> First thing I saw upon a quick review was we were relying on our own
> curband for RX instead of the cfg80211 hw->conf band. Now granted
> that *may* be updated properly, and it seems that may be the case,
Looks good at first glance, except it conflicts with changes I
recently posted. I'm all for getting rid of driver copies of stuff
in the stack.
> - /* NB: setup here so ath5k_rate_update is happy */
> - if (test_bit(AR5K_MODE_11A, ah->ah_modes))
> - ath5k_setcurmode(sc, AR5K_MODE_11A);
> - else
> - ath5k_setcurmode(sc, AR5K_MODE_11B);
> -
I take it ath5k_rate_update didn't really care?
> ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
> {
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "(%u MHz) -> (%u MHz)\n",
> - sc->curchan->center_freq, chan->center_freq);
> + sc->hw->conf.channel->center_freq, chan->center_freq);
So, does hw->conf.channel change before we're told to change channel,
or after?
> - if (chan) {
> - ath5k_hw_set_imr(ah, 0);
> - ath5k_txq_cleanup(sc);
> - ath5k_rx_stop(sc);
> -
> - sc->curchan = chan;
> - sc->curband = &sc->sbands[chan->band];
> - }
Unless I missed something I think we still want:
if (chan_change)
ath5k_chan_set(...);
> - ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, chan != NULL);
> + ret = ath5k_hw_reset(ah, sc->opmode, chan, chan_change);
There's just no synchronization of this stuff, not too surprising there
are races.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Johannes Berg @ 2009-08-26 14:34 UTC (permalink / raw)
To: htl10
Cc: Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless, Luis R. Rodriguez
In-Reply-To: <850984.89698.qm@web23108.mail.ird.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
> > Or wait ... are you using compat-wireless?
>
> Yes, I am. I mentioned this and did wonder if the _backport/ part
> in /sys/class is important.
Sorry, didn't see.
Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
some compat*.h but obviously the kernel won't ever call that notifier,
so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
handle that -- it'll be working fine in a regular tree.
Luis, the only way to handle that would be to manually call the PRE_UP
notifier from mac80211's subif_open() and if that returns an error
(warning: the calling convention is weird) return the error... that's
weird but would work.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [Bug #14016] mm/ipw2200 regression
From: Andrew Morton @ 2009-08-26 14:44 UTC (permalink / raw)
To: Mel Gorman
Cc: Johannes Weiner, Pekka Enberg, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List,
Bartlomiej Zolnierkiewicz, Mel Gorman, netdev, linux-mm, Zhu Yi,
James Ketrenos, Reinette Chatre, linux-wireless, ipw2100-devel
In-Reply-To: <20090826093747.GA10955@csn.ul.ie>
(cc IPW maintainers and mailing lists)
On Wed, 26 Aug 2009 10:37:49 +0100 Mel Gorman <mel@csn.ul.ie> wrote:
> On Wed, Aug 26, 2009 at 10:27:41AM +0200, Johannes Weiner wrote:
> > [Cc netdev]
> >
> > On Wed, Aug 26, 2009 at 09:09:44AM +0300, Pekka Enberg wrote:
> > > On Tue, Aug 25, 2009 at 11:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > >
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.30. __Please verify if it still should be listed and let me know
> > > > (either way).
> > > >
> > > > Bug-Entry __ __ __ : http://bugzilla.kernel.org/show_bug.cgi?id=14016
> > > > Subject __ __ __ __ : mm/ipw2200 regression
> > > > Submitter __ __ __ : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > > > Date __ __ __ __ __ __: 2009-08-15 16:56 (11 days old)
> > > > References __ __ __: http://marc.info/?l=linux-kernel&m=125036437221408&w=4
> > >
> > > If am reading the page allocator dump correctly, there's plenty of
> > > pages left but we're unable to satisfy an order 6 allocation. There's
> > > no slab allocator involved so the page allocator changes that went
> > > into 2.6.31 seem likely. Mel, ideas?
> >
> > It's an atomic order-6 allocation, the chances for this to succeed
> > after some uptime become infinitesimal. The chunks > order-2 are
> > pretty much exhausted on this dump.
> >
> > 64 pages, presumably 256k, for fw->boot_size while current ipw
> > firmware images have ~188k. I don't know jack squat about this
> > driver, but given the field name and the struct:
> >
> > struct ipw_fw {
> > __le32 ver;
> > __le32 boot_size;
> > __le32 ucode_size;
> > __le32 fw_size;
> > u8 data[0];
> > };
> >
> > fw->boot_size alone being that big sounds a bit fishy to me.
> >
>
> Agreed. While there are a low number of order-6 pages free in the page
> allocation failure dump, there are not enough for watermarks to be
> satisified. As it's atomic, there is little that can be done from a VM
> perspective and it's the responsibility of the driver. I'm no driver expert
> but I'll have a go at fixing it anyway.
>
> My reading of this is that the firmware is being loaded from a workqueue and
> I am failing to see any restriction on sleeping in the path. It would appear
> that the driver just used the most convenient *_alloc_coherent function
> available forgetting that it assumes GFP_ATOMIC. Can someone who does know
> which way is up with a driver tell me why the patch below might not
> work?
>
> Bartlomiej, any chance you could give this a spin? Preferably, you'd
> have preempt enabled and CONFIG_DEBUG_SPINLOCK_SLEEP on as well because
> that combination will complain loudly if we really can't sleep in this
> path.
>
> =====
> ipw2200: Avoid large GFP_ATOMIC allocation during firmware loading
>
> ipw2200 uses pci_alloc_consistent() to allocate a large coherent buffer for
> the loading of firmware which is an order-6 allocation of GFP_ATOMIC. At
> system start-up time, this is not a problem. However, the firmware on the
> card can get confused and the corrective action taken is to reload the
> firmware and reinit the card. High-order GFP_ATOMIC allocations of this
> type can and will fail when the system is already up and running.
>
> As the firmware is loaded from a workqueue, it should be possible for
> the driver to go to sleep. This patch converts the call of
> pci_alloc_consistent() which assumes GFP_ATOMIC to dma_alloc_coherent()
> which can specify its own flags.
>
> The big downside with this patch is that it uses GFP_REPEAT to avoid the
> driver unloading. There is potential that this will cause a reclaim
> storm as the machine tries to find a free order-6 buffer. A suggested
> alternative for the driver owner is in the comments.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> ---
> drivers/net/wireless/ipw2x00/ipw2200.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> index 44c29b3..f2e251e 100644
> --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> @@ -3167,7 +3167,19 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * data, size_t len)
> u8 *shared_virt;
>
> IPW_DEBUG_TRACE("<< : \n");
> - shared_virt = pci_alloc_consistent(priv->pci_dev, len, &shared_phys);
> +
> + /*
> + * This is a whopping large allocation, in or around order-6 so
> + * dma_alloc_coherent is used to specify the GFP_KERNEL|__GFP_REPEAT
> + * flags. Note that this action means the system could go into a
> + * reclaim loop until it cannot reclaim any more trying to satisfy
> + * the allocation. It would be preferable if one buffer is allocated
> + * at driver initialisation and reused when the firmware needs to
> + * be reloaded, overwriting the existing firmware each time
> + */
> + shared_virt = dma_alloc_coherent(
> + priv->pci_dev == NULL ? NULL : &priv->pci_dev->dev,
> + len, &shared_phys, GFP_KERNEL|__GFP_REPEAT);
>
> if (!shared_virt)
> return -ENOMEM;
Of course, the risk of making a change like this is that we'll then go
and leave it there.
To fix this code properly we should, as you say, stop doing an order-6
allocation altogether.
And right now I think it's doing _two_ order-6 allocations:
shared_virt = pci_alloc_consistent(priv->pci_dev, len, &shared_phys);
if (!shared_virt)
return -ENOMEM;
memmove(shared_virt, data, len);
whoever allocated `data' is being obnoxious as well.
It is perhaps pretty simple to make the second (GFP_ATOMIC) allocation
go away. The code is already conveniently structured to do this:
do {
chunk = (struct fw_chunk *)(data + offset);
offset += sizeof(struct fw_chunk);
/* build DMA packet and queue up for sending */
/* dma to chunk->address, the chunk->length bytes from data +
* offeset*/
/* Dma loading */
rc = ipw_fw_dma_add_buffer(priv, shared_phys + offset,
le32_to_cpu(chunk->address),
le32_to_cpu(chunk->length));
if (rc) {
IPW_DEBUG_INFO("dmaAddBuffer Failed\n");
goto out;
}
offset += le32_to_cpu(chunk->length);
} while (offset < len);
what is the typical/expected value of chunk->length here? If it's
significantly less than 4096*(2^6), could we convert this function to
use a separate DMAable allocation per fw_chunk?
^ permalink raw reply
* Re: 2.6.31-rc7-git2: Reported regressions 2.6.29 -> 2.6.30
From: Andrew Morton @ 2009-08-26 14:53 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, DRI,
Linux SCSI List, Network Development, Linux Wireless List,
Natalie Protasevich, Linux ACPI, Kernel Testers List,
Linus Torvalds, Linux PM List
In-Reply-To: <b170af450908260147o60427997ne6b9872198893c41@mail.gmail.com>
On Wed, 26 Aug 2009 10:47:13 +0200 Rafa__ Mi__ecki <zajec5@gmail.com> wrote:
> 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?
>
I'm not seeing any linux-acpi emails from Len since August 14.
So I merged this patch and shall send it along with
thermal_sys-check-get_temp-return-value.patch
acpi-dont-call-acpi_processor_init-if-acpi-is-disabled.patch
in to Linus today.
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Hin-Tak Leung @ 2009-08-26 15:07 UTC (permalink / raw)
To: Johannes Berg
Cc: htl10, Larry Finger, Herton Ronaldo Krzesinski, linux-wireless,
Luis R. Rodriguez
In-Reply-To: <1251297273.15619.11.camel@johannes.local>
On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>
>> > Or wait ... are you using compat-wireless?
>>
>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>> in /sys/class is important.
>
> Sorry, didn't see.
>
> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
> some compat*.h but obviously the kernel won't ever call that notifier,
> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
> handle that -- it'll be working fine in a regular tree.
>
> Luis, the only way to handle that would be to manually call the PRE_UP
> notifier from mac80211's subif_open() and if that returns an error
> (warning: the calling convention is weird) return the error... that's
> weird but would work.
Okay, that explains it. So I can have a Tested-by: ... I just grep for
NETDEV_PRE_UP in compat-wireless and it is only in
include/net/compat-2.6.31.h (not in 2.6.30) and I am on 2.6.30.5-X . I
can grab the rawhide 2.6.31 rpms and try it quickly;
and possibly look at some ugly quick hack backport that? Stay tuned.
Thanks for the help.
Hin-Tak
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: John W. Linville @ 2009-08-26 15:03 UTC (permalink / raw)
To: Richard Farina
Cc: Larry Finger, Herton Ronaldo Krzesinski, Hin-Tak Leung,
linux-wireless
In-Reply-To: <4A94B01E.9040309@gmail.com>
On Tue, Aug 25, 2009 at 11:46:38PM -0400, 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.
> 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.
commit 3da7429ce92abd79b14e2275a28be144ce2c3013
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Tue Jul 14 15:55:16 2009 -0500
rtl8187: Fix for kernel oops when unloading with LEDs enabled
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>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The above commit is in linux-2.6 since v2.6.31-rc2. If it isn't in
compat-wireless, I have no idea why.
Hth...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] clarify licensing of rfkill utility
From: John W. Linville @ 2009-08-26 15:37 UTC (permalink / raw)
To: linux-wireless
Cc: Johannes Berg, Marcel Holtmann, Tim Gardner, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
What do you think? A nicer alternative might be to make all of it
GPL2...
COPYING | 7 +
COPYING.Linux | 356 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
core.h | 4 +
3 files changed, 367 insertions(+), 0 deletions(-)
create mode 100644 COPYING.Linux
diff --git a/COPYING b/COPYING
index 8351a30..f299f42 100644
--- a/COPYING
+++ b/COPYING
@@ -1,3 +1,10 @@
+Since rfkill.h comes from Linux, COPYING.Linux applies to it. All other
+bits are governed by the Copyright notice below.
+
+---
+
+Copyright 2009 Johannes Berg <johannes@sipsolutions.net>
+
Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
diff --git a/COPYING.Linux b/COPYING.Linux
new file mode 100644
index 0000000..ca442d3
--- /dev/null
+++ b/COPYING.Linux
@@ -0,0 +1,356 @@
+
+ NOTE! This copyright does *not* cover user programs that use kernel
+ services by normal system calls - this is merely considered normal use
+ of the kernel, and does *not* fall under the heading of "derived work".
+ Also note that the GPL below is copyrighted by the Free Software
+ Foundation, but the instance of code that it refers to (the Linux
+ kernel) is copyrighted by me and others who actually wrote it.
+
+ Also note that the only valid version of the GPL as far as the kernel
+ is concerned is _this_ particular version of the license (ie v2, not
+ v2.2 or v3.x or whatever), unless explicitly otherwise stated.
+
+ Linus Torvalds
+
+----------------------------------------
+
+ GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+ 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users. This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it. (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.) You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have. You must make sure that they, too, receive or can get the
+source code. And you must show them these terms so they know their
+rights.
+
+ We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+ Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software. If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+ Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary. To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+\f
+ GNU GENERAL PUBLIC LICENSE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License. The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language. (Hereinafter, translation is included without limitation in
+the term "modification".) Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+ 1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+ 2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+ a) You must cause the modified files to carry prominent notices
+ stating that you changed the files and the date of any change.
+
+ b) You must cause any work that you distribute or publish, that in
+ whole or in part contains or is derived from the Program or any
+ part thereof, to be licensed as a whole at no charge to all third
+ parties under the terms of this License.
+
+ c) If the modified program normally reads commands interactively
+ when run, you must cause it, when started running for such
+ interactive use in the most ordinary way, to print or display an
+ announcement including an appropriate copyright notice and a
+ notice that there is no warranty (or else, saying that you provide
+ a warranty) and that users may redistribute the program under
+ these conditions, and telling the user how to view a copy of this
+ License. (Exception: if the Program itself is interactive but
+ does not normally print such an announcement, your work based on
+ the Program is not required to print an announcement.)
+\f
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+ 3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+ a) Accompany it with the complete corresponding machine-readable
+ source code, which must be distributed under the terms of Sections
+ 1 and 2 above on a medium customarily used for software interchange; or,
+
+ b) Accompany it with a written offer, valid for at least three
+ years, to give any third party, for a charge no more than your
+ cost of physically performing source distribution, a complete
+ machine-readable copy of the corresponding source code, to be
+ distributed under the terms of Sections 1 and 2 above on a medium
+ customarily used for software interchange; or,
+
+ c) Accompany it with the information you received as to the offer
+ to distribute corresponding source code. (This alternative is
+ allowed only for noncommercial distribution and only if you
+ received the program in object code or executable form with such
+ an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it. For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable. However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+\f
+ 4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License. Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+ 5. You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or
+distribute the Program or its derivative works. These actions are
+prohibited by law if you do not accept this License. Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+ 6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions. You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+ 7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all. For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices. Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+\f
+ 8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded. In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+ 9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation. If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+ 10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission. For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this. Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+ NO WARRANTY
+
+ 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+ 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+ END OF TERMS AND CONDITIONS
+\f
+ How to Apply These Terms to Your New Programs
+
+ If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+ To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+ <one line to give the program's name and a brief idea of what it does.>
+ Copyright (C) <year> <name of author>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+ Gnomovision version 69, Copyright (C) year name of author
+ Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License. Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+ `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+ <signature of Ty Coon>, 1 April 1989
+ Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs. If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library. If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/core.h b/core.h
index 56cde40..91ce9a3 100644
--- a/core.h
+++ b/core.h
@@ -1,3 +1,7 @@
+/*
+ * Copyright 2009 Johannes Berg <johannes@sipsolutions.net>
+ */
+
#ifndef __CORE
#define __CORE
--
1.6.2.5
^ permalink raw reply related
* [PATCH 0/8] ath9k: WLAN-BT coexistence clean up and 3-wire support
From: Vasanthakumar Thiagarajan @ 2009-08-26 15:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
John,
This series has WLAN-BT coex 3-wire support and clean ups in BT coex
part.
Vasanth
Vasanthakumar Thiagarajan (8):
ath9k: Split ath9k_hw_btcoex_enable() into two logical pieces
ath9k: Move btcoex stuff from hw.[ch] to new btcoex.[ch]
ath9k: Configure btcoex register during every reset
ath9k: Move btcoex related data to a separate struct
ath9k: Determine btcoex scheme type based on chip version
ath9k: Remove hw capability bit meant for btcoex
ath9k: Add infrastructure for generic hw timers
ath9k: Add Bluetooth Coexistence 3-wire support
drivers/net/wireless/ath/ath9k/Makefile | 3 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 5 +
drivers/net/wireless/ath/ath9k/btcoex.c | 319 +++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/btcoex.h | 98 ++++++++++
drivers/net/wireless/ath/ath9k/debug.h | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 239 +++++++++++++++++++++--
drivers/net/wireless/ath/ath9k/hw.h | 57 +++++-
drivers/net/wireless/ath/ath9k/main.c | 33 +++-
drivers/net/wireless/ath/ath9k/reg.h | 64 ++++++-
drivers/net/wireless/ath/ath9k/xmit.c | 9 +-
10 files changed, 795 insertions(+), 34 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath9k/btcoex.c
create mode 100644 drivers/net/wireless/ath/ath9k/btcoex.h
^ 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