* Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
From: Luciano Coelho @ 2013-07-04 14:21 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-wireless, tony, nsekhar, mturquette, mark.rutland, balbi,
grant.likely, rob.herring, devicetree-discuss, linux-doc,
linux-kernel, linux-omap, linux-arm-kernel, nm
In-Reply-To: <CAAwP0s3xkqUGnGvojfpyQq97qUmKCqY3BD4RyK1_uuX=pNy91g@mail.gmail.com>
On Wed, 2013-07-03 at 17:12 +0200, Javier Martinez Canillas wrote:
> On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho <coelho@ti.com> wrote:
> > On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
> >> The platform_quirk element in the platform data was used to change the
> >> way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
> >> the irqflags used and treat edge trigger differently from the rest.
> >>
> >> Instead of hiding this irq flag setting behind the quirk, have the
> >> board files set the flags during initialization. This will be more
> >> meaningful than driver-specific quirks when we switch to DT.
> >>
> >> Additionally, fix missing gpio_request() calls in the boarding files
> >> (so that setting the flags actually works).
> >>
> >> Cc: Tony Lindgren <tony@atomide.com>
> >> Cc: Sekhar Nori <nsekhar@ti.com>
> >> Signed-off-by: Luciano Coelho <coelho@ti.com>
> >> ---
> >
> > [...]
> >
> >> @@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
> >> wlcore_adjust_conf(wl);
> >>
> >> wl->irq = platform_get_irq(pdev, 0);
> >> - wl->platform_quirks = pdata->platform_quirks;
> >> wl->if_ops = pdev_data->if_ops;
> >>
> >> - if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
> >> - irqflags = IRQF_TRIGGER_RISING;
> >> - else
> >> - irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
> >> + irq_data = irq_get_irq_data(wl->irq);
> >> + if (!irq_data) {
> >> + wl1271_error("couldn't get irq data for irq %d\n", wl->irq);
> >> + ret = -EINVAL;
> >> + goto out_free_nvs;
> >> + }
> >> +
> >> + wl->irq_flags = irqd_get_trigger_type(irq_data);
> >
> > BTW, there seems to be a patch on its way to make reading the flags
> > easier (ie. no need to get the irq_data first):
> >
> > http://mid.gmane.org/1367945288-5625-1-git-send-email-javier@dowhile0.org
> >
> > I'm not sure if this is going to be taken in, but if it does, it would
> > be nice to change the code here to use the new irq_get_trigger_type()
> > function.
> That patch has been already merged in Linus tree as commit 1f6236bf
> ("genirq: Add irq_get_trigger_type() to get IRQ flags").
>
> So yes, it would be better if you can use irq_get_trigger_type()
> instead calling irq_get_irq_data() + irqd_get_trigger_type().
That's great, thanks! I'll make this change as soon as I get your patch
into my tree (ie. after the merge window closes).
--
Luca.
^ permalink raw reply
* Re: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Daniel Drake @ 2013-07-04 14:32 UTC (permalink / raw)
To: Bing Zhao
Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <477F20668A386D41ADCC57781B1F70430EA2E0674B@SC-VEXCH1.marvell.com>
On Wed, Jul 3, 2013 at 4:39 PM, Bing Zhao <bzhao@marvell.com> wrote:
> Followings are the actions taken for driver unload.
>
> a) If device is connected, sync deauth command is sent.
> b) Auto deep sleep is cancelled by sending sync command
> c) Sync shutdown command is queued and HW_STATUS is changed to reset.
> d) Now no other command gets queued based on HW_STATUS.
> e) Wait for shutdown command response and handle it.
> f) Set surprise_removed flag which blocks SDIO interrupts
>
> As per our design, we don't send any command to firmware after SHUTDOWN command. Also, firmware doesn't send any interrupt after SHUTDOWN command response.
I cannot see how the driver behaviour matches the above description
for when the card is removed as the system is suspended. For example I
cannot see where the SHUTDOWN command gets sent in such cases.
Also, at which point do we wait upon all async commands to complete
before shutting down? I walked through all the driver code in the
codepaths hit when the card is removed as the system is going into
suspend, and I found no such point. (This is why interrupts then
arrive later, because those commands are completing.)
Daniel
^ permalink raw reply
* Re: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Daniel Drake @ 2013-07-04 14:37 UTC (permalink / raw)
To: Bing Zhao
Cc: Amitkumar Karwar, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <CAMLZHHSSfPnWK957Yd+vrLrsPHtUDW3b4ZxSjMe2SdpaQPk5hQ@mail.gmail.com>
On Thu, Jul 4, 2013 at 8:32 AM, Daniel Drake <dsd@laptop.org> wrote:
> I cannot see how the driver behaviour matches the above description
> for when the card is removed as the system is suspended. For example I
> cannot see where the SHUTDOWN command gets sent in such cases.
>
> Also, at which point do we wait upon all async commands to complete
> before shutting down? I walked through all the driver code in the
> codepaths hit when the card is removed as the system is going into
> suspend, and I found no such point. (This is why interrupts then
> arrive later, because those commands are completing.)
Also, from a more general standpoint, I would say it is bad
practice/design to leave an interrupt handler running but in a state
where it does not ACK interrupts. You're just asking for trouble. If
you really don't expect interrupts beyond a certain point, and bad
things would happen if interrupts *were* to arrive for any valid or
invalid reason, disable the interrupt and remove the handler at that
point.
Daniel
^ permalink raw reply
* Re: [RFC 42/53] wireless-regdb: ID, Indonesia - enable 5 GHz and VHT80
From: Paul Stewart @ 2013-07-04 17:51 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John Linville, wireless-regdb, linux-wireless
In-Reply-To: <1372899889-19183-43-git-send-email-mcgrof@do-not-panic.com>
On Wed, Jul 3, 2013 at 6:04 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
>
> From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
>
> Pursuant to:
>
> http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf,
>
> provide a 5GHz rule for Indonesian regulatory domain. QCA has
> also verified VHT80 can be enabled. Patch originally posted by
> Paul Stewart <pstew@chromium.org>, I just modified to enable 80 MHz
> bandwidth.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
>
> ---
>
> db.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/db.txt b/db.txt
> index 0ebb934..a101b1e 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -380,7 +380,9 @@ country HU: DFS-ETSI
> (57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOOR
>
> country ID:
> + # ref: http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf
> (2402 - 2482 @ 40), (N/A, 20)
> + (5735 - 5815 @ 20), (N/A, 20)
>
> country IE: DFS-ETSI
> (2402 - 2482 @ 40), (N/A, 20)
> --
> 1.7.10.4
>
> --
> 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: [RFC 42/53] wireless-regdb: ID, Indonesia - enable 5 GHz and VHT80
From: Arend van Spriel @ 2013-07-04 18:23 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, wireless-regdb, linux-wireless
In-Reply-To: <1372899889-19183-43-git-send-email-mcgrof@do-not-panic.com>
On 07/04/2013 03:04 AM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
>
> Pursuant to:
>
> http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf,
>
> provide a 5GHz rule for Indonesian regulatory domain. QCA has
> also verified VHT80 can be enabled. Patch originally posted by
> Paul Stewart <pstew@chromium.org>, I just modified to enable 80 MHz
> bandwidth.
Hi Luis,
Is it just me or did you make a typo. Should '@ 20' be '@ 80' ?
Gr. AvS
> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
> ---
> db.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/db.txt b/db.txt
> index 0ebb934..a101b1e 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -380,7 +380,9 @@ country HU: DFS-ETSI
> (57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOOR
>
> country ID:
> + # ref: http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf
> (2402 - 2482 @ 40), (N/A, 20)
> + (5735 - 5815 @ 20), (N/A, 20)
>
> country IE: DFS-ETSI
> (2402 - 2482 @ 40), (N/A, 20)
>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 4/5] rt2x00: rt2800lib: introduce rt2800_eeprom_word_index helper
From: Stanislaw Gruszka @ 2013-07-04 18:27 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <51D4883E.2050607@openwrt.org>
Hi
On Wed, Jul 03, 2013 at 10:23:26PM +0200, Gabor Juhos wrote:
> > I have two nit-picks, but they can be fixed later on top of your current
> > patches.
> >
> >> + if (WARN_ON(word >= EEPROM_WORD_COUNT)) {
> >> + rt2x00_warn(rt2x00dev, "invalid EEPROM word %d\n", word);
> >> + return 0;
> >> + }
> >
> > Since we take "enum rt2800_eeprom_word" as word argument, it can not
> > have different values than already listed, so this warning is not needed.
>
> EEPROM_WORD_COUNT is listed in the enums and the word argument can be equal to
> that, however it is not a valid index for the EEPROM map. Additionally, if
> someone puts a new enum value after EEPROM_WORD_COUNT by mistake that will be an
> invalid index as well.
I do not feel that there is big chance that someone will do such
mistakes, but yes, they are at least theoretically possible, so warning
can stay.
> My reason behind the rt2x00_warn call was that it shows the wiphy name. If you
> are testing different devices in parallel it is good to know which one causes
> the warning. However I can use 'wiphy_name(rt2x00dev->hw->wiphy)' to get that
> information.
>
> I will send a follow-up patch which removes the rt2x00_warn calls. Do you also
> prefer WARN_ONCE instead of WARN?
I prefer WARN_ONCE variant to avoid possible spamming dmesg with lot of
warnings.
Thanks
Stanislaw
^ permalink raw reply
* Re: [RFC 42/53] wireless-regdb: ID, Indonesia - enable 5 GHz and VHT80
From: Krishna Chaitanya @ 2013-07-04 19:29 UTC (permalink / raw)
To: Arend van Spriel
Cc: Luis R. Rodriguez, linville, wireless-regdb, linux-wireless
In-Reply-To: <51D5BD9D.5020604@broadcom.com>
On Thu, Jul 4, 2013 at 11:53 PM, Arend van Spriel <arend@broadcom.com> wrote:
>
> On 07/04/2013 03:04 AM, Luis R. Rodriguez wrote:
>>
>> From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
>>
>> Pursuant to:
>>
>> http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf,
>>
>> provide a 5GHz rule for Indonesian regulatory domain. QCA has
>> also verified VHT80 can be enabled. Patch originally posted by
>> Paul Stewart <pstew@chromium.org>, I just modified to enable 80 MHz
>> bandwidth.
>
>
> Hi Luis,
>
> Is it just me or did you make a typo. Should '@ 20' be '@ 80' ?
But as per the document shared above the maximum BW allowed is 20MHz only, no?
So is the VHT80 tested by QCA compliant to the reg rules?
^ permalink raw reply
* [PATCH] include: net: Add parameter desc to fix warning when generating docs
From: Sam Bristow @ 2013-07-04 21:18 UTC (permalink / raw)
To: Johannes Berg, David S. Miller
Cc: linux-wireless, netdev, linux-kernel, Sam Bristow
'make htmldocs' was generating a warning about a missing parameter description
for gfp.
---
include/net/cfg80211.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 26b5b69..159e070 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4153,6 +4153,7 @@ void cfg80211_report_wowlan_wakeup(struct wireless_dev *wdev,
* cfg80211_crit_proto_stopped() - indicate critical protocol stopped by driver.
*
* @wdev: the wireless device for which critical protocol is stopped.
+ * @gfp: allocation flags
*
* This function can be called by the driver to indicate it has reverted
* operation back to normal. One reason could be that the duration given
--
1.8.3.1
^ permalink raw reply related
* [PATCH] include: net: Add parameter desc to fix waring when generating docs
From: Sam Bristow @ 2013-07-04 21:59 UTC (permalink / raw)
To: Johannes Berg, David S. Miller
Cc: linux-wireless, netdev, linux-kernel, Sam Bristow
'make htmldocs' was generating a warning about a missing parameter description
for gfp.
Earlier patch was missing my signed-off-by line...
Signed-off-by: Sam Bristow <sam.bristow@gmail.com>
---
include/net/cfg80211.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 26b5b69..159e070 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4153,6 +4153,7 @@ void cfg80211_report_wowlan_wakeup(struct wireless_dev *wdev,
* cfg80211_crit_proto_stopped() - indicate critical protocol stopped by driver.
*
* @wdev: the wireless device for which critical protocol is stopped.
+ * @gfp: allocation flags
*
* This function can be called by the driver to indicate it has reverted
* operation back to normal. One reason could be that the duration given
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] include: net: Add parameter desc to fix waring when generating docs
From: Luciano Coelho @ 2013-07-04 22:43 UTC (permalink / raw)
To: Sam Bristow
Cc: Johannes Berg, David S. Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1372975190-21117-1-git-send-email-sam.bristow@gmail.com>
On Fri, 2013-07-05 at 09:59 +1200, Sam Bristow wrote:
> 'make htmldocs' was generating a warning about a missing parameter description
> for gfp.
>
> Earlier patch was missing my signed-off-by line...
> Signed-off-by: Sam Bristow <sam.bristow@gmail.com>
> ---
You have a typo in the patch subject (it was not there in your previous
version ;).
Also, you shouldn't add explanations about the different versions of the
patch in the commit message (in you case the "Earlier patch was missing
my signed-off-by line..." text). If you want to add this kind of
comments, add it after the "---" under the Signed-of tags.
One more thing, it's a good idea to use [PATCH v2] when you're sending a
second version of the same patch. That can be easily done with git
format-patch (and also with git send-email) by using an argument like
this: --subject-prefix="PATCH v2"
--
Luca.
^ permalink raw reply
* [PATCH] mac80211: Handle zero RTS threshold
From: Sujith Manoharan @ 2013-07-05 5:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The spec says:
"Setting this attribute to 0 has the effect of turning on the RTS/CTS
handshake for all frames of Data or Management type transmitted by this
STA."
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
net/mac80211/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 4105d0c..50c7309 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -651,7 +651,8 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
tx->sdata->vif.type == NL80211_IFTYPE_ADHOC);
/* set up RTS protection if desired */
- if (len > tx->local->hw.wiphy->rts_threshold) {
+ if (!tx->local->hw.wiphy->rts_threshold ||
+ (len > tx->local->hw.wiphy->rts_threshold)) {
txrc.rts = true;
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] include: net: Add parameter desc to fix warning when generating docs
From: Johannes Berg @ 2013-07-05 7:14 UTC (permalink / raw)
To: Sam Bristow; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <1372972701-18323-1-git-send-email-sam.bristow@gmail.com>
On Fri, 2013-07-05 at 09:18 +1200, Sam Bristow wrote:
> 'make htmldocs' was generating a warning about a missing parameter description
> for gfp.
Thanks, but I already have it in my tree. Also, you forgot to sign off
on the patch anyway.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Handle zero RTS threshold
From: Johannes Berg @ 2013-07-05 7:15 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: linux-wireless
In-Reply-To: <1373003143-29211-1-git-send-email-sujith@msujith.org>
On Fri, 2013-07-05 at 11:15 +0530, Sujith Manoharan wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> The spec says:
>
> "Setting this attribute to 0 has the effect of turning on the RTS/CTS
> handshake for all frames of Data or Management type transmitted by this
> STA."
Maybe we should set it to 0xffffffff in cfg80211 to make it simpler for
drivers?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: enable HT overrides for ibss
From: Johannes Berg @ 2013-07-05 7:49 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372408799-25651-2-git-send-email-siwu@hrz.tu-chemnitz.de>
> + /* on the next assoc, re-program HT parameters */
assoc??
^ permalink raw reply
* Re: [PATCH] mac80211: Handle zero RTS threshold
From: Sujith Manoharan @ 2013-07-05 8:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1373008522.8548.1.camel@jlt4.sipsolutions.net>
Johannes Berg wrote:
> Maybe we should set it to 0xffffffff in cfg80211 to make it simpler for
> drivers?
The patch is broken, please disregard it.
Sujith
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: enable HT overrides for ibss
From: Simon Wunderlich @ 2013-07-05 8:59 UTC (permalink / raw)
To: Johannes Berg
Cc: Simon Wunderlich, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1373010572.8548.2.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 266 bytes --]
On Fri, Jul 05, 2013 at 09:49:32AM +0200, Johannes Berg wrote:
>
> > + /* on the next assoc, re-program HT parameters */
>
> assoc??
What is wrong with that? Should I write "join" instead? This was merely
copied from mac80211/mlme.c :)
Cheers,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* ath: Unable to remove station entry
From: Michael Tokarev @ 2013-07-05 9:01 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
Hello.
Recently I bought a TP-Link TL-WN821N v3 802.11n USB adaptor,
and tried to use it as an access point for a small Wireless LAN.
It works fine so far, except of one issue.
Quite often to be really annoying, it stops working with the
following message in kernel log:
Jul 5 09:51:26 gnome vmunix: [133814.449408] ath: Unable to remove station entry for: 38:aa:3c:02:07:f1
after this, the interface is stuck, it can't be seen over WIFI,
and any attempt to do anything with it inside the host results
in more processes entering D state (initially right when this
happens, there's a kworker process in D state).
For example, `rmmod ath9k_htc' - which appears to be a topmost
module on the stack - results in rmmod entering D state, with
the following stack:
rmmod D 000000010266c10c 0 10684 10643 0x00000000
ffffffff8148b020 0000000000000082 0000000000012400 ffff88012ae9d7d0
ffff880114843fd8 ffff880114843fd8 ffff880114843fd8 ffff88012ae9d7d0
0000000125aa5040 ffffffff8148b020 0000000000012400 ffff8801298cb500
Call Trace:
[<ffffffff81367a59>] ? __schedule+0x3a9/0x960
[<ffffffff810558f0>] ? usleep_range+0x40/0x40
[<ffffffff81368e38>] ? __mutex_lock_slowpath+0xc8/0x140
[<ffffffff813689ba>] ? mutex_lock+0x1a/0x40
[<ffffffffa025bc66>] ? ath9k_wmi_cmd+0xc6/0x200 [ath9k_htc]
[<ffffffffa02614d8>] ? ath9k_regread+0x38/0x50 [ath9k_htc]
[<ffffffffa0076849>] ? ath_hw_keyreset+0x59/0x220 [ath]
[<ffffffffa0076a2d>] ? ath_key_delete+0x1d/0xdc [ath]
[<ffffffffa025edc5>] ? ath9k_htc_set_key+0x85/0x130 [ath9k_htc]
[<ffffffffa0230d19>] ? ieee80211_key_disable_hw_accel+0x89/0x130 [mac80211]
[<ffffffffa0230ddc>] ? __ieee80211_key_destroy+0x1c/0x80 [mac80211]
[<ffffffffa0231505>] ? ieee80211_free_keys+0x45/0x80 [mac80211]
[<ffffffffa02233a7>] ? ieee80211_do_stop+0x1f7/0x5c0 [mac80211]
[<ffffffff812d9f40>] ? dev_deactivate_many+0x1f0/0x240
[<ffffffffa0223785>] ? ieee80211_stop+0x15/0x20 [mac80211]
[<ffffffff812bc505>] ? __dev_close_many+0x85/0xd0
[<ffffffff812bc638>] ? dev_close_many+0x98/0x110
[<ffffffff812bc788>] ? rollback_registered_many+0xd8/0x250
[<ffffffff812bc90e>] ? unregister_netdevice_many+0xe/0x60
[<ffffffffa0222f00>] ? ieee80211_remove_interfaces+0xc0/0x100 [mac80211]
[<ffffffffa0211096>] ? ieee80211_unregister_hw+0x46/0x110 [mac80211]
[<ffffffffa02624c4>] ? ath9k_htc_disconnect_device+0x54/0xd0 [ath9k_htc]
[<ffffffffa025b3a2>] ? ath9k_hif_usb_disconnect+0x52/0x150 [ath9k_htc]
[<ffffffffa005dd52>] ? usb_unbind_interface+0x42/0x150 [usbcore]
[<ffffffff81274546>] ? __device_release_driver+0x76/0xe0
[<ffffffff81274bf0>] ? driver_detach+0xa0/0xb0
[<ffffffff812743d0>] ? bus_remove_driver+0x70/0xc0
[<ffffffffa005d7a6>] ? usb_deregister+0xa6/0xc0 [usbcore]
[<ffffffffa0262d36>] ? ath9k_htc_exit+0x6/0x16 [ath9k_htc]
[<ffffffff81080ee2>] ? sys_delete_module+0x132/0x260
[<ffffffff8136a245>] ? page_fault+0x25/0x30
[<ffffffff81371552>] ? system_call_fastpath+0x16/0x1b
followed by:
Jul 5 10:02:27 gnome vmunix: [134474.473451] ath: Unable to remove interface at idx: 0
(rmmod is stuck forever).
Now, in order to make the interface to work again, the only way I
found so far is to _reboot_ the machine. For example, re-plugging
the USB cord does not help, because, as far as I can see, the driver
is in some weird state and can't initialize the new interface.
This is a 3.2.0-stable kernel (right now 3.2.46), x86-64 (amd64),
self-compiled, without additional patches.
There are a few references to this message on the 'net, including
one mentioning this very card (in russian) --
http://forums.opensuse.org/p-russian/dhydhdhdhdhundhdhdh/1046-1077-1083-1077-1079-1086/469022-wifi-usb-tp-link-tl-wn821n.html
they claim the problem has been fixed for _some_ by upgrading the
BIOS on the motherboard. Maybe this is actually related, because
as far as I can tell, this started happening _after_ I upgraded
BIOS on my motherboard, so it may be related to the bios changes.
I don't recall whenever I noticed this erratic behavour before I
upgraded BIOS. Looking at the BIOS history, I don't see anything
interesting about USB in the changelog, except this:
* Fixed issue with Fast Boot so USB devices still work under DOS
if USB Optimization is enabled.
This is an intel atom-based D2500CC board, with the latest BIOS.
I had to update bios because of another issue which is now fixed,
but I can't go back to the old bios because the old one was too
old and current motherboard refuses to flash it.
What can be done to diagnose the problem? I can give a more recent
kernel a try, but I'd love to see it fixed for a -stable kernel which
is used by several major distributions. Also, the problem is not
easy to trigger, the system may work for a few days without issues
or may stop working in a few hours, irrespective of the load (f.e.
the above example at 09:51 was me awakening my android phone just
to see what time it is now, and it trying to connect/disconnect
to/from the default wifi network -- there were no other devices
using wifi at that time).
Thanks,
/mjt
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 1/5] rt2x00: rt2800lib: introduce rt2800_eeprom_word enum
From: Helmut Schaa @ 2013-07-05 9:05 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Gabor Juhos, John Linville, linux-wireless, rt2x00 Users List
In-Reply-To: <20130703191417.GA2245@localhost.localdomain>
On Wed, Jul 3, 2013 at 9:14 PM, Stanislaw Gruszka <stf_xl@wp.pl> wrote:
> On Wed, Jun 26, 2013 at 07:55:14PM +0200, Gabor Juhos wrote:
>> The patch converts the EEPROM_* word address defines
>> into new enum values. The new enum type will be used
>> by new functions which will be introduced in subsequent
>> changes.
>>
>> The patch contains no functional changes.
>>
>> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Nice! Just had a quick glance at the series. Looks good to me.
Thanks,
Helmut
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: enable HT overrides for ibss
From: Johannes Berg @ 2013-07-05 9:56 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372408799-25651-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Applied both (with assoc->join)
johannes
^ permalink raw reply
* Re: [PATCH V2] vlan priority handling in WMM
From: Johannes Berg @ 2013-07-05 9:57 UTC (permalink / raw)
To: cedric.voncken; +Cc: linux-wireless
In-Reply-To: <1372319520-29087-1-git-send-email-cedric.voncken@acksys.fr>
Subject line should have a "wireless: " (or "cfg80211: ") prefix.
> If the VLAN tci is set in skb->vlan_tci use the priority field to determine the WMM priority.
>
> V2 modifications :
> Fix indentation
> Use symbolic constant
> include the header linux/if_vlan.h
This doesn't belong into the changelog, it should be after --- with the
diffstat.
johannes
^ permalink raw reply
* Re: [PATCH V2] vlan priority handling in WMM
From: Johannes Berg @ 2013-07-05 9:59 UTC (permalink / raw)
To: cedric.voncken; +Cc: linux-wireless
In-Reply-To: <1372319520-29087-1-git-send-email-cedric.voncken@acksys.fr>
> + vlan_priority = (skb->vlan_tci & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
> + if (vlan_priority > 0)
> + return vlan_priority;
Is this really correct? For once, checking vlan_priority for non-zero
seems weird since that ought to be a valid value -- is there no other
way to determine that the value is valid?
Also, this gives you a 2-bit value, while the return value should be a
3-bit value, maybe you need to shift this up by one to spread into the
correct buckets?
johannes
^ permalink raw reply
* Re: configuring Generic Information Elements (genie)
From: Dennis New @ 2013-07-05 10:39 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20130704092329.a9f5ce506984b78a878fb4bf@dennisn.dyndns.org>
On Thu, 4 Jul 2013 09:23:29 -0400, Dennis New wrote:
> Is there a way to configure (i.e. disable) the "generic information
> elements" that are listed, for example, by "iwlist genie" ?
>
> I have an open ad-hoc network, and whereas one of my wifi cards shows
> "no generic IE (Operation not supported)", and works fine, my other
> card shows:
>
> IE: IEEE 802.11i/WPA2 Version 1
> Group Cipher : CCMP
> Pairwise Ciphers (1) : CCMP
> Authentication Suites (1) : PSK
>
> which seems to be causing problems on some (probably buggy) machines
> that incorrectly think it's using WPA2.
It seems like only a few wireless drivers implement this genie thing,
(just ipw2x00, orinoco and prism54). For the moment, I just hacked
disabled the SIOCSIWGENIE handler from
drivers/net/wireless/ipw2x00/ipw2200.c. Things work now.
^ permalink raw reply
* [PATCH 04/16] ath10k: do not setup rts/frag thresholds for suspended interfaces
From: Kalle Valo @ 2013-07-05 13:15 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Michal Kazior
In-Reply-To: <1373030117-18077-1-git-send-email-kvalo@qca.qualcomm.com>
From: Michal Kazior <michal.kazior@tieto.com>
mac80211 calls for rts/frag threshold hooks before
any interface is brought back up again when
resuming.
We would set vdev parameters before given vdev is
created lading to a FW crash.
rts/frag thresholds will be re-set accordingly in
add_interface() hook anyway.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index ff0bb38..cdee800 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2597,7 +2597,7 @@ static int ath10k_set_rts_threshold(struct ieee80211_hw *hw, u32 value)
mutex_lock(&ar->conf_mutex);
ieee80211_iterate_active_interfaces_atomic(
- hw, IEEE80211_IFACE_ITER_RESUME_ALL,
+ hw, IEEE80211_IFACE_ITER_NORMAL,
ath10k_set_rts_iter, &ar_iter);
mutex_unlock(&ar->conf_mutex);
@@ -2639,7 +2639,7 @@ static int ath10k_set_frag_threshold(struct ieee80211_hw *hw, u32 value)
mutex_lock(&ar->conf_mutex);
ieee80211_iterate_active_interfaces_atomic(
- hw, IEEE80211_IFACE_ITER_RESUME_ALL,
+ hw, IEEE80211_IFACE_ITER_NORMAL,
ath10k_set_frag_iter, &ar_iter);
mutex_unlock(&ar->conf_mutex);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 01/16] ath10k: fix teardown ordering
From: Kalle Valo @ 2013-07-05 13:15 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Michal Kazior
In-Reply-To: <1373030117-18077-1-git-send-email-kvalo@qca.qualcomm.com>
From: Michal Kazior <michal.kazior@tieto.com>
This should fix memory corruption if HIF is tried
to be restarted.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 8e4e832..1bd381f 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1263,7 +1263,6 @@ static void ath10k_pci_hif_stop(struct ath10k *ar)
ath10k_pci_process_ce(ar);
ath10k_pci_cleanup_ce(ar);
ath10k_pci_buffer_cleanup(ar);
- ath10k_pci_ce_deinit(ar);
}
static int ath10k_pci_hif_exchange_bmi_msg(struct ath10k *ar,
@@ -2332,6 +2331,7 @@ static void ath10k_pci_remove(struct pci_dev *pdev)
tasklet_kill(&ar_pci->msi_fw_err);
ath10k_core_unregister(ar);
+ ath10k_pci_ce_deinit(ar);
ath10k_pci_stop_intr(ar);
pci_set_drvdata(pdev, NULL);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 00/16] ath10k: pending patches
From: Kalle Valo @ 2013-07-05 13:15 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel
Hi,
here are pending patches which were commited to ath10k.git while
ath10k was under review. They were only sent to ath9k-devel, I'm
resending them now before I reapply them to my new ath.git tree.
Michal Kazior (16):
ath10k: fix teardown ordering
ath10k: fix possible deadlock
ath10k: setup rts/frag thresholds upon vdev creation
ath10k: do not setup rts/frag thresholds for suspended interfaces
ath10k: remove ath10k_bus
ath10k: fix typo in define name
ath10k: silent warning in IBSS mode
ath10k: lower print level for a message
ath10k: provide errno if bmi read/write fails
ath10k: change function to take struct ath10k as arg
ath10k: rename hif callback
ath10k: embed HTC struct inside ath10k
ath10k: embed HTT struct inside ath10k
ath10k: improve locking
ath10k: abort scan properly if wmi_scan_stop fails
ath10k: add missing debug prints
drivers/net/wireless/ath/ath10k/bmi.c | 6 +-
drivers/net/wireless/ath/ath10k/ce.c | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 42 +++++-------
drivers/net/wireless/ath/ath10k/core.h | 15 ++---
drivers/net/wireless/ath/ath10k/hif.h | 10 +--
drivers/net/wireless/ath/ath10k/htc.c | 30 +++------
drivers/net/wireless/ath/ath10k/htc.h | 4 +-
drivers/net/wireless/ath/ath10k/htt.c | 27 ++++----
drivers/net/wireless/ath/ath10k/htt.h | 3 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 3 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 12 ++--
drivers/net/wireless/ath/ath10k/mac.c | 107 +++++++++++++++++++++++++-----
drivers/net/wireless/ath/ath10k/pci.c | 23 +++----
drivers/net/wireless/ath/ath10k/pci.h | 4 +-
drivers/net/wireless/ath/ath10k/wmi.c | 14 ++--
15 files changed, 180 insertions(+), 122 deletions(-)
--
1.7.9.5
^ 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