* RE: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Chauhan, Rajesh @ 2013-10-17 17:19 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Rodriguez, Luis, Malinen, Jouni,
Bahini, Henri, Chang, Leo, Luo, Xun, Chauhan, Rajesh
In-Reply-To: <1382020835.14410.16.camel@jlt4.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50LiBQdXJwb3NlIG9mIHRoaXMg
cGF0Y2ggaXMgdG8gYWRkIGFuIEFQSSBmb3IgV0xBTiBkcml2ZXIgdG8gcmVwb3J0IGZyZXF1ZW5j
eSByYW5nZXMgd2hpY2ggc2hvdWxkIGJlIGF2b2lkZWQgZm9yIFNBUC9QMlAtR08gYmVjYXVzZSBv
ZiBpbnRlcmZlcmVuY2UuDQoNCkhvdyBhYm91dCBpZiBJIHJld29yZCBjb21taXQgdGVzdCBhcyBi
ZWxvdz8NCg0KY2ZnODAyMTEvbmw4MDIxMTogQWRkIEFQSSB0byByZXBvcnQgZnJlcXVlbmN5IHJh
bmdlKHMpIHRvIGJlIGF2b2lkZWQNCg0KQWRkIHN1cHBvcnQgZm9yIFdMQU4gZHJpdmVyIHRvIHJl
cG9ydCBmcmVxdWVuY3kgcmFuZ2UocykgdG8gYmUgYXZvaWRlZCBiZWNhdXNlIG9mIGludGVyZmVy
ZW5jZS4gSWYgU0FQL1AyUC1HTyBpcyBvcGVyYXRpbmcgb24gaW50ZXJmZXJpbmcgZnJlcXVlbmN5
IHRoZW4gdXNlciBzcGFjZSBzaG91bGQgc3RvcCBhbmQgcmVzdGFydCB0aGVtIGF2b2lkaW5nIGlu
dGVyZmVyaW5nIGZyZXF1ZW5jeSByYW5nZShzKS4gVXNlciBzcGFjZSBtYXkgZGVjaWRlIHRvIGNv
bnRpbnVlIG9wZXJhdGlvbiBvbiBpbnRlcmZlcmluZyBmcmVxdWVuY3ksIGJ1dCBpbiBzdWNoIGNh
c2UsIHRoZXJlIG1pZ2h0IGJlIGltcGFjdCBvbiBwZXJmb3JtYW5jZS4NCg0KUmVnYXJkcywNClJh
amVzaCBDaGF1aGFuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaGFu
bmVzIEJlcmcgW21haWx0bzpqb2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0XSANClNlbnQ6IFRodXJz
ZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDc6NDEgQU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IFJvZHJpZ3VleiwgTHVpczsgTWFsaW5lbiwg
Sm91bmkNClN1YmplY3Q6IFJlOiBbUEFUQ0hdIGNmZzgwMjExL25sODAyMTE6IEFkZCBzdXBwb3J0
IHRvIHJlcG9ydCB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlcyhzKQ0KDQpPbiBXZWQsIDIwMTMtMTAt
MTYgYXQgMjE6NTcgLTA3MDAsIFJhamVzaCBDaGF1aGFuIHdyb3RlOg0KPiBBZGQgc3VwcG9ydCBm
b3IgV0xBTiBkcml2ZXIgdG8gcmVwb3J0IHVuc2FmZSBmcmVxdWVuY3kgcmFuZ2UocykuIA0KDQpX
aHk/DQoNCj4gVXNlcg0KPiBzcGFjZSBzaG91bGQgbW92ZSBTQVAvUDJQLUdPIG91dCBvZiB0aG9z
ZSB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlKHMpLg0KPiBVc2VyIHNwYWNlIG1heSBkZWNpZGUgdG8g
Y29udGludWUgb3BlcmF0aW9uIG9uIHVuc2FmZSBmcmVxdWVuY3kgYnV0IGluIA0KPiBzdWNoIGNh
c2UgdGhlcmUgbWlnaHQgYmUgaW1wYWN0IG9uIHBlcmZvcm1hbmNlIGJlY2F1c2Ugb2YgaW50ZXJm
ZXJlbmNlLg0KDQpTQVA/IEkgZG9uJ3QgdGhpbmsgU0FQIHdpbGwgbW92ZSAtIHRoZXkncmUgcHJl
dHR5IHN0dWNrIGluIFdhbGxkb3JmIDpQDQoNClRoaXMgaXMgcHJldHR5IHN0cmFuZ2UgcGF0Y2gs
IGFuZCB2ZXJ5IGxpdHRsZSBqdXN0aWZpY2F0aW9uLg0KDQoiVW5zYWZlIiBpcyBhbHNvIGEgcmVh
bGx5IGJhZCB3b3JkLg0KDQpqb2hhbm5lcw0KDQo=
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Will Hawkins @ 2013-10-17 16:19 UTC (permalink / raw)
To: Johannes Berg, Detlev Casanova
Cc: Dan Williams, linux-wireless, laurent.pinchart
In-Reply-To: <1382020735.14410.14.camel@jlt4.sipsolutions.net>
On 10/17/2013 10:38 AM, Johannes Berg wrote:
> On Fri, 2013-10-11 at 17:43 +0200, Detlev Casanova wrote:
>
>>>>>> occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
>>>>
>>>> ("cfg80211:
>>>>>> use DS or HT operation IEs to determine BSS channel")
>>>
>>> [...]
>>>
>>>> I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
>>>> the problem seems to be fixed.
>>>
>>> Huh, that's odd. Did 0.7.3 use wext driver?
>>
>> Yes it did.
>
> Hmm. Even taking that into account though I don't really see any
> difference.
>
> Maybe you could check if there's any difference in iwlist scan output
> before/after the patch (for the affected AP)?
>
> johannes
Not to clog up the channel, but I was running into exactly the same
problem. I expected to see the problem somewhere in the kernel, etc. I
turned on debugging and kernel tracing and saw nothing. The fix for me
is almost identical to the fix that Detlev first described.
However, the problem for me was somewhere else entirely. The access
point was sending out malformed beacon messages that kept it from
showing up.
I *hope* that this helps. However, I hope, at least, this was not a
waste of bits. :-)
Will
>
>
> --
> 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: [PATCH v5 4/5] {nl,cfg,mac}80211: implement mesh channel switch userspace API
From: Johannes Berg @ 2013-10-17 16:02 UTC (permalink / raw)
To: Chun-Yeow Yeoh
Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <CAHS2MGMgTp9homs-moVXTVfyFtcuYPPbHBiiW0XD9kBYJ0hb5w@mail.gmail.com>
On Thu, 2013-10-17 at 23:52 +0800, Chun-Yeow Yeoh wrote:
> > If this fails, do we leak the CSA settings?
> If failed, beacon won't include the CSA settings. But If there is any
> other calling mesh_rebuild_beacon and succeed, the it will be included
> up if the channel switch count is not expired. At the same time, CSA
> action frame is also transmitted, so others may use this to start the
> CSA process.
That part makes sense. But we propagate the error up, and then we
probably never call the finish function?
johannes
^ permalink raw reply
* Re: [PATCH v5 4/5] {nl,cfg,mac}80211: implement mesh channel switch userspace API
From: Chun-Yeow Yeoh @ 2013-10-17 15:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <1382022683.14410.18.camel@jlt4.sipsolutions.net>
> If this fails, do we leak the CSA settings?
If failed, beacon won't include the CSA settings. But If there is any
other calling mesh_rebuild_beacon and succeed, the it will be included
up if the channel switch count is not expired. At the same time, CSA
action frame is also transmitted, so others may use this to start the
CSA process.
Am I answer your question?
----
Chun-Yeow
^ permalink raw reply
* Re: [PATCH v5 0/5] Add Mesh Channel Switch Support
From: Johannes Berg @ 2013-10-17 15:12 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1381802911-3921-1-git-send-email-yeohchunyeow@cozybit.com>
I've applied patches 1-3 and there's one question on patch 4.
johannes
^ permalink raw reply
* Re: [PATCH v5 4/5] {nl,cfg,mac}80211: implement mesh channel switch userspace API
From: Johannes Berg @ 2013-10-17 15:11 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1381802911-3921-5-git-send-email-yeohchunyeow@cozybit.com>
On Mon, 2013-10-14 at 19:08 -0700, Chun-Yeow Yeoh wrote:
> +int ieee80211_mesh_csa_beacon(struct ieee80211_sub_if_data *sdata,
> + struct cfg80211_csa_settings *csa_settings,
> + bool csa_action)
> +{
> + struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
> + struct mesh_csa_settings *tmp_csa_settings;
> + int ret = 0;
> +
> + if (csa_action)
> + ieee80211_send_action_csa(sdata, csa_settings);
> +
> + tmp_csa_settings = kmalloc(sizeof(*tmp_csa_settings),
> + GFP_ATOMIC);
> + if (!tmp_csa_settings)
> + return -ENOMEM;
> +
> + memcpy(&tmp_csa_settings->settings, csa_settings,
> + sizeof(struct cfg80211_csa_settings));
> +
> + rcu_assign_pointer(ifmsh->csa, tmp_csa_settings);
> +
> + ret = ieee80211_mesh_rebuild_beacon(sdata);
> + if (ret)
> + return -EINVAL;
If this fails, do we leak the CSA settings?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: store the channel in wdev upon ibss_join
From: Antonio Quartulli @ 2013-10-17 14:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1382021488.14410.17.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
On Thu, Oct 17, 2013 at 04:51:28PM +0200, Johannes Berg wrote:
> On Thu, 2013-10-17 at 16:48 +0200, Antonio Quartulli wrote:
> > On Thu, Oct 17, 2013 at 04:36:28PM +0200, Johannes Berg wrote:
> > > On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> > > > From: Antonio Quartulli <antonio@open-mesh.com>
> > > >
> > > > To allow cfg80211 to use the real channel to pick up the
> > > > proper (i)bss object, store the used channel in
> > > > wdev->channel during ibss_join
> > >
> > > WTF? No, mac80211 can't just randomly modify cfg80211-owned data.
> >
> > Mh, ok. :)
> >
> > What about setting wdev->channel in __cfg80211_join_ibss() right after having
> > set wdev->ssid ?
> > This way we leave mac80211 out and we totally handle this thing in cfg80211
> > only.
>
> Locking might be problematic though. I also don't know where else the
> channel might be used?
I don't think it is used elsewhere in IBSS mode
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: store the channel in wdev upon ibss_join
From: Johannes Berg @ 2013-10-17 14:51 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <20131017144824.GH2596@neomailbox.net>
On Thu, 2013-10-17 at 16:48 +0200, Antonio Quartulli wrote:
> On Thu, Oct 17, 2013 at 04:36:28PM +0200, Johannes Berg wrote:
> > On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> > > From: Antonio Quartulli <antonio@open-mesh.com>
> > >
> > > To allow cfg80211 to use the real channel to pick up the
> > > proper (i)bss object, store the used channel in
> > > wdev->channel during ibss_join
> >
> > WTF? No, mac80211 can't just randomly modify cfg80211-owned data.
>
> Mh, ok. :)
>
> What about setting wdev->channel in __cfg80211_join_ibss() right after having
> set wdev->ssid ?
> This way we leave mac80211 out and we totally handle this thing in cfg80211
> only.
Locking might be problematic though. I also don't know where else the
channel might be used?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: store the channel in wdev upon ibss_join
From: Antonio Quartulli @ 2013-10-17 14:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1382020588.14410.12.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Thu, Oct 17, 2013 at 04:36:28PM +0200, Johannes Berg wrote:
> On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> > From: Antonio Quartulli <antonio@open-mesh.com>
> >
> > To allow cfg80211 to use the real channel to pick up the
> > proper (i)bss object, store the used channel in
> > wdev->channel during ibss_join
>
> WTF? No, mac80211 can't just randomly modify cfg80211-owned data.
Mh, ok. :)
What about setting wdev->channel in __cfg80211_join_ibss() right after having
set wdev->ssid ?
This way we leave mac80211 out and we totally handle this thing in cfg80211
only.
(I think with this change patch 1/2 makes more sense?)
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Johannes Berg @ 2013-10-17 14:40 UTC (permalink / raw)
To: Rajesh Chauhan; +Cc: linux-wireless, rodrigue, jouni
In-Reply-To: <1381985833-31312-1-git-send-email-rajeshc@qca.qualcomm.com>
On Wed, 2013-10-16 at 21:57 -0700, Rajesh Chauhan wrote:
> Add support for WLAN driver to report unsafe frequency range(s).
Why?
> User
> space should move SAP/P2P-GO out of those unsafe frequency range(s).
> User space may decide to continue operation on unsafe frequency but in
> such case there might be impact on performance because of interference.
SAP? I don't think SAP will move - they're pretty stuck in Walldorf :P
This is pretty strange patch, and very little justification.
"Unsafe" is also a really bad word.
johannes
^ permalink raw reply
* Re: [PATCH 3.12] rt2800usb: slow down TX status polling
From: Larry Finger @ 2013-10-17 14:39 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: users
In-Reply-To: <20131017100431.GA9603@redhat.com>
On 10/17/2013 05:04 AM, Stanislaw Gruszka wrote:
> Polling TX statuses too frequently has two negative effects. First is
> randomly peek CPU usage, causing overall system functioning delays.
> Second bad effect is that device is not able to fill TX statuses in
> H/W register on some workloads and we get lot of timeouts like below:
>
> ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
> ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
> ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
>
> This not only cause flood of messages in dmesg, but also bad throughput,
> since rate scaling algorithm can not work optimally.
>
> In the future, we should probably make polling interval be adjusted
> automatically, but for now just increase values, this make mentioned
> problems gone.
>
> Resolve:
> https://bugzilla.kernel.org/show_bug.cgi?id=62781
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> drivers/net/wireless/rt2x00/rt2800usb.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index 96677ce5..e095e61 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -176,8 +176,8 @@ static bool rt2800usb_tx_sta_fifo_read_completed(struct rt2x00_dev *rt2x00dev,
> queue_work(rt2x00dev->workqueue, &rt2x00dev->txdone_work);
>
> if (rt2800usb_txstatus_pending(rt2x00dev)) {
> - /* Read register after 250 us */
> - hrtimer_start(&rt2x00dev->txstatus_timer, ktime_set(0, 250000),
> + /* Read register after 1 ms */
> + hrtimer_start(&rt2x00dev->txstatus_timer, ktime_set(0, 1000000),
> HRTIMER_MODE_REL);
> return false;
> }
> @@ -202,8 +202,8 @@ static void rt2800usb_async_read_tx_status(struct rt2x00_dev *rt2x00dev)
> if (test_and_set_bit(TX_STATUS_READING, &rt2x00dev->flags))
> return;
>
> - /* Read TX_STA_FIFO register after 500 us */
> - hrtimer_start(&rt2x00dev->txstatus_timer, ktime_set(0, 500000),
> + /* Read TX_STA_FIFO register after 2 ms */
> + hrtimer_start(&rt2x00dev->txstatus_timer, ktime_set(0, 2000000),
> HRTIMER_MODE_REL);
> }
I suggest getting rid of the magic numbers as long as you are making this
change. A single define could handle the delay time for the two cases.
Larry
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Johannes Berg @ 2013-10-17 14:38 UTC (permalink / raw)
To: Detlev Casanova; +Cc: Dan Williams, linux-wireless, laurent.pinchart
In-Reply-To: <3301062.MLBKDh0Ksv@naboo>
On Fri, 2013-10-11 at 17:43 +0200, Detlev Casanova wrote:
> > > > > occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
> > >
> > > ("cfg80211:
> > > > > use DS or HT operation IEs to determine BSS channel")
> >
> > [...]
> >
> > > I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
> > > the problem seems to be fixed.
> >
> > Huh, that's odd. Did 0.7.3 use wext driver?
>
> Yes it did.
Hmm. Even taking that into account though I don't really see any
difference.
Maybe you could check if there's any difference in iwlist scan output
before/after the patch (for the affected AP)?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: add ieee80211_tx_prepare_skb() helper function
From: Johannes Berg @ 2013-10-17 14:37 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1381766460-84515-1-git-send-email-nbd@openwrt.org>
On Mon, 2013-10-14 at 18:01 +0200, Felix Fietkau wrote:
> This can be used by a driver to prepare skbs for transmission, which were
> obtained via functions such as ieee80211_probereq_get or
> ieee80211_nullfunc_get.
>
> This is useful for drivers that want to send those frames directly, but
> need rate control information to be prepared first.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: store the channel in wdev upon ibss_join
From: Johannes Berg @ 2013-10-17 14:36 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1381790282-1146-2-git-send-email-antonio@meshcoding.com>
On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> To allow cfg80211 to use the real channel to pick up the
> proper (i)bss object, store the used channel in
> wdev->channel during ibss_join
WTF? No, mac80211 can't just randomly modify cfg80211-owned data.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: on ibss_joined use the channel to get the proper bss object
From: Johannes Berg @ 2013-10-17 14:35 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1381790282-1146-1-git-send-email-antonio@meshcoding.com>
On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> It may be the case that the same IBSS (same bssid and essid)
> exists on two different channels (i.e. two IBSSes created
> with different but fixed freq) and therefore the latter must
> be also used to distinguish them.
>
> Fix wdev->current_bss assignment by passing the channel to
> cfg80211_get_bss() on ibss_joined.
> This ensures that cfg80211_get_bss() picks up the proper bss
> object.
This makes no sense, wdev->channel should always be NULL (unless the
same wdev was in AP or mesh mode first and that somehow leaked out?)
johannes
^ permalink raw reply
* Re: [PATCH 1/6] cfg80211: export reg_initiator_name()
From: Johannes Berg @ 2013-10-17 14:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <1381797731-2454-2-git-send-email-mcgrof@do-not-panic.com>
On Mon, 2013-10-14 at 17:42 -0700, Luis R. Rodriguez wrote:
> Drivers can now use this to parse the regulatory request and
> be more verbose when needed.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: fix channel to frequency mapping in 5.9GHz range
From: Johannes Berg @ 2013-10-17 14:33 UTC (permalink / raw)
To: Dennis H Jensen; +Cc: linville, linux-wireless
In-Reply-To: <1381830012.3711.50.camel@djensen-laptop>
On Tue, 2013-10-15 at 11:40 +0200, Dennis H Jensen wrote:
> > Yes, but then before 5910 would have been channel 182. Now you're making
> > it channel 197. That doesn't really make sense at all.
>
> OK, fair enough, but the fact is that there is a hole in the frequencies
> that were added in 802.11p.
802.11p ... yeah, that's an issue.
> > > In case that doesn't do it. What is needed to get channel 182 to be 5910
> > > MHz as Annex E defines for the US and Europe? Channel to frequency
> > > mapping based on operating class?
> >
> > Annex E is the 802.11 spec, to get something into that ...
>
> You misunderstood me; the European operating class 14, for example,
> states that channel 182 is to be 5910.
That's a 10MHz channel only.
In any case, I don't see a good way out. Pretending that the channel
number is something else like you did in this patch is clearly wrong and
will obviously lead to interoperability issues.
I think we need to actually start taking the operating class (or maybe
just the starting frequency) into account in the kernel. How we do that
I don't really know.
johannes
^ permalink raw reply
* Re: [PATCH 00/21] rt2x00: separate rt2800 PCI and SoC driver
From: Helmut Schaa @ 2013-10-17 14:31 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John W. Linville, linux-wireless, rt2x00 Users List
In-Reply-To: <1381995755-16471-1-git-send-email-juhosg@openwrt.org>
On Thu, Oct 17, 2013 at 9:42 AM, Gabor Juhos <juhosg@openwrt.org> wrote:
> The rt2800pci driver supports both PCI and SoC device. To achieve
> this, the code uses several ifdef statements which makes the code
> quite ugly. The patch set introduces a shared module, and moves the
> SoC driver into a separate module to get rid of the mess.
Nice series. Does this also reduce module size on when building for
SoC without PCI support?
Helmut
^ permalink raw reply
* Re: [PATCH] mac80211: fixes for mesh powersave logic
From: Johannes Berg @ 2013-10-17 14:30 UTC (permalink / raw)
To: Marco Porsch; +Cc: linux-wireless, devel
In-Reply-To: <1381832964-3684-1-git-send-email-marco@cozybit.com>
On Tue, 2013-10-15 at 12:29 +0200, Marco Porsch wrote:
> This patch fixes errors in the mesh powersave logic which
> cause that remote peers do not get peer power mode change
> notifications and mesh peer service periods (MPSPs) got
> stuck.
>
> When closing a peer link, set the (now invalid) peer-specific
> power mode to 'unknown'.
>
> Avoid overhead when local power mode is unchanged.
>
> Reliably clear MPSP flags on peering status update.
>
> Avoid MPSP flags getting stuck by not requesting a further
> MPSP ownership if we already are an MPSP owner.
Applied to -next, there are too many unimportant and unrelated changes
in this patch for me to send it to 3.12 at this point.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Remove check for offchannel state when waking netdev queues
From: Johannes Berg @ 2013-10-17 14:28 UTC (permalink / raw)
To: Seth Forshee; +Cc: linux-wireless
In-Reply-To: <1381871781-29128-1-git-send-email-seth.forshee@canonical.com>
On Tue, 2013-10-15 at 16:16 -0500, Seth Forshee wrote:
> 6c17b77b67587b9f9e3070fb89fe98cef3187131 ensures that a device's
> mac80211 queues will remain stopped while offchannel. Since the
> vif can no longer be offchannel when the queues wake it's not
> necessary to check for this before waking its netdev queues.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] ath10k: add error handling to ath10k_pci_wait()
From: Kalle Valo @ 2013-10-17 14:27 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQ=x+KJxXtcdMYKEGGjfF3oryTXgA2N+4OAa+6fcSAK4uw@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 17 October 2013 01:36, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> ath10k_pci_wait() didn't notify any errors to callers, it
>> just printed a warning so add proper error handling.
>>
>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
[...]
>> @@ -2227,7 +2231,13 @@ static int ath10k_pci_start_intr_legacy(struct ath10k *ar)
>> ar_pci->mem + PCIE_LOCAL_BASE_ADDRESS +
>> PCIE_SOC_WAKE_ADDRESS);
>>
>> - ath10k_pci_wait(ar);
>> + ret = ath10k_pci_wait(ar);
>> + if (ret) {
>> + ath10k_warn("Failed to enable legacy interrupt, target did not wake up: %d\n",
>> + ret);
>> + free_irq(ar_pci->pdev->irq, ar);
>> + return ret;
>> + }
>
> I think we could actually use ath10k_do_pci_wake/sleep() here (see
> above iowrite). It does basically the same thing - sets the wake
> register and waits until HW wakes up. I think ath10k_pci_wait() could
> even go away.
That would be nice, I'll take a look. Thanks for the review.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/5] rfkill-gpio: ACPI support
From: Johannes Berg @ 2013-10-17 14:26 UTC (permalink / raw)
To: Heikki Krogerus
Cc: John W. Linville, Rhyland Klein, Rafael J. Wysocki, linux-acpi,
linux-wireless, netdev
In-Reply-To: <1381920823-15403-1-git-send-email-heikki.krogerus@linux.intel.com>
On Wed, 2013-10-16 at 13:53 +0300, Heikki Krogerus wrote:
> Hi,
>
> The first patches prepare the driver for the support. The last patch
> can then add the support quite easily. With these patches, adding DT
> support later will be quite straight forward if someone needs it.
Applied. I'm totally relying on all the reviewers though, since I have
very little idea of what's going on. If anyone else wants to maintain
the rfkill-gpio driver I'd welcome that :-)
johannes
^ permalink raw reply
* Re: [PATCH] ath10k: add error handling to ath10k_pci_wait()
From: Michal Kazior @ 2013-10-17 14:24 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <20131017083615.31028.25088.stgit@localhost6.localdomain6>
On 17 October 2013 01:36, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> ath10k_pci_wait() didn't notify any errors to callers, it
> just printed a warning so add proper error handling.
>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath10k/pci.c | 28 ++++++++++++++++++++++++----
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
> index 1e9cfcc9..92759cd 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -525,15 +525,19 @@ static bool ath10k_pci_target_is_awake(struct ath10k *ar)
> return (RTC_STATE_V_GET(val) == RTC_STATE_V_ON);
> }
>
> -static void ath10k_pci_wait(struct ath10k *ar)
> +static int ath10k_pci_wait(struct ath10k *ar)
> {
> int n = 100;
>
> while (n-- && !ath10k_pci_target_is_awake(ar))
> msleep(10);
>
> - if (n < 0)
> + if (n < 0) {
> ath10k_warn("Unable to wakeup target\n");
> + return -ETIMEDOUT;
> + }
> +
> + return 0;
> }
>
> int ath10k_do_pci_wake(struct ath10k *ar)
> @@ -2227,7 +2231,13 @@ static int ath10k_pci_start_intr_legacy(struct ath10k *ar)
> ar_pci->mem + PCIE_LOCAL_BASE_ADDRESS +
> PCIE_SOC_WAKE_ADDRESS);
>
> - ath10k_pci_wait(ar);
> + ret = ath10k_pci_wait(ar);
> + if (ret) {
> + ath10k_warn("Failed to enable legacy interrupt, target did not wake up: %d\n",
> + ret);
> + free_irq(ar_pci->pdev->irq, ar);
> + return ret;
> + }
I think we could actually use ath10k_do_pci_wake/sleep() here (see
above iowrite). It does basically the same thing - sets the wake
register and waits until HW wakes up. I think ath10k_pci_wait() could
even go away.
>
> /*
> * A potential race occurs here: The CORE_BASE write
> @@ -2290,6 +2300,10 @@ static int ath10k_pci_start_intr(struct ath10k *ar)
> }
>
> ret = ath10k_pci_start_intr_legacy(ar);
> + if (ret) {
> + ath10k_warn("Failed to start legacy interrupts: %d\n", ret);
> + return ret;
> + }
>
> exit:
> ar_pci->num_msi_intrs = num;
> @@ -2315,13 +2329,19 @@ static int ath10k_pci_reset_target(struct ath10k *ar)
> {
> struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
> int wait_limit = 300; /* 3 sec */
> + int ret;
>
> /* Wait for Target to finish initialization before we proceed. */
> iowrite32(PCIE_SOC_WAKE_V_MASK,
> ar_pci->mem + PCIE_LOCAL_BASE_ADDRESS +
> PCIE_SOC_WAKE_ADDRESS);
>
> - ath10k_pci_wait(ar);
> + ret = ath10k_pci_wait(ar);
> + if (ret) {
> + ath10k_warn("Failed to reset target, target did not wake up: %d\n",
> + ret);
> + return ret;
> + }
Ditto.
Michał
^ permalink raw reply
* Re: [PATCH] mac80211_hwsim: Add iface comb for DFS
From: Johannes Berg @ 2013-10-17 13:44 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: linux-wireless
In-Reply-To: <1381773079-2678-1-git-send-email-janusz.dziedzic@tieto.com>
On Mon, 2013-10-14 at 19:51 +0200, Janusz Dziedzic wrote:
> Add iface combination that allow DFS support.
> Add also debugfs dfs_simulate_radar file that
> can be used to simulate radar event.
> This could be usefull for mac80211/cfg80211/
typo: useful
> @@ -1714,6 +1716,7 @@ static void mac80211_hwsim_free(void)
>
> list_for_each_entry_safe(data, tmpdata, &tmplist, list) {
> debugfs_remove(data->debugfs_group);
> + debugfs_remove(data->debugfs_radar);
I think it would be good to convert to debugfs_remove_recursive first -
that avoids the need for the new dentry pointer as well as the remove
here. Can you do that (as a separate patch)?
> +static int hwsim_write_simulate_radar(void *dat, u64 val)
> +{
> + struct mac80211_hwsim_data *data = dat;
> +
> + ieee80211_radar_detected(data->hw);
> +
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(hwsim_simulate_radar, NULL,
> + hwsim_write_simulate_radar, "%llu\n");
Does the u64 make sense? Probably doesn't matter much, but seems weird
to be so specific for a file that really doesn't care about the value?
johannes
^ permalink raw reply
* Re: [PATCH 3.12] mac80211: disable WMM with invalid parameters
From: Johannes Berg @ 2013-10-17 13:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Antonio Quartulli
In-Reply-To: <1381995881-16935-1-git-send-email-johannes@sipsolutions.net>
On Thu, 2013-10-17 at 09:44 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Some APs (notably a Sitecom WL-153 v1 with firmware 1.45) are sending
> invalid WMM parameters setting AIFSN, ECWmin and ECWmax to zero. The
> spec mandates that the value of AIFSN is at least 2, and some cards
> (e.g. Intel with the iwldvm driver) can't transmit when the invalid
> QoS parameters are actually uploaded to the firmware.
>
> Since there's little chance of being able to guess the values that
> the AP actually meant, disable WMM if such an invalid case is found.
> Since ECWmin/ECWmax are allowed to be zero, only verify AIFSN >= 2
> and ECWmin <= ECWmax.
I've applied a fixed version.
johannes
^ 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