* [PATCH] ieee80211: add definition for interworking support
From: Bing Zhao @ 2013-07-27 0:02 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Avinash Patil, Bing Zhao
From: Avinash Patil <patila@marvell.com>
IEEE802.11u interworking support is advertised via extended
capabilities IE bit 31. This is 7th bit of 4th byte of extended
capabilities.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
include/linux/ieee80211.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index b0dc87a..22c9094 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1860,6 +1860,11 @@ enum ieee80211_tdls_actioncode {
WLAN_TDLS_DISCOVERY_REQUEST = 10,
};
+/* Interworking capabilities are set in 7th bit of 4th byte of the
+ * @WLAN_EID_EXT_CAPABILITY information element
+ */
+#define WLAN_EXT_CAPA4_INTERWORKING_ENABLED BIT(7)
+
/*
* TDLS capabililites to be enabled in the 5th byte of the
* @WLAN_EID_EXT_CAPABILITY information element
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 0/2] beacon measurement (beacon filtering disable)
From: Kalle Valo @ 2013-07-27 5:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: emmanuel.grumbach, linux-wireless
In-Reply-To: <1374825838.8248.6.camel@jlt4.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2013-07-17 at 07:10 +0300, Kalle Valo wrote:
>> Johannes Berg <johannes@sipsolutions.net> writes:
>>
>> > We have beacon filtering (to reduce host wakeups) in our device,
>> > but for some measurement/debug purposes we need to turn it off.
>>
>> TBH I'm not really fond of this. I'm not really sure what's the use
>> case but first this sounded a like a factory test for me, not something
>> which a regular user would want to do.
Sure, that's good to do. I'm just worried that if we add a new command
to enable/disable each small feature we will have a lot of commands in
nl80211. But I guess that's not a problem as you are the maintainer
anyway :)
But I do see benefits from this, so I guess in the end this is good to
have. It would be nice if someone would add a similar command for BT
coexistance as well, that always seems to be a common source of
problems.
> Yeah, in a way that's true. FWIW, we could also connect it to testmode
> and not worry about it for upstream, but it seemed that others might
> want/need similar functionality.
>
>> Can't we connect this to power save? When disabling power save we could
>> also disable beacon filtering and would not need a separate command.
>
> I'm not so sure that's a good idea. While superficially beacon filtering
> is related to saving power, it's really a different thing - it's about
> CPU/host power while powersave is about device power (RX chains etc.)
> Connecting them, in particular where disabling beacon filtering isn't
> even supported by all devices, doesn't really seem like a good idea,
> particularly not for any tool that would require such functionality.
Makes sense.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] [PATCH] mac80211: handle VHT radiotap info for tx status
From: Karl Beldan @ 2013-07-27 8:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Karl Beldan
In-Reply-To: <1374861514-29022-1-git-send-email-karl.beldan@gmail.com>
On Fri, Jul 26, 2013 at 07:58:34PM +0200, Karl Beldan wrote:
> From: Karl Beldan <karl.beldan@rivierawaves.com>
>
> The radiotap VHT info is 12 bytes (required to be aligned on 2) :
> u16 known - IEEE80211_RADIOTAP_VHT_KNOWN_*
> u8 flags - IEEE80211_RADIOTAP_VHT_FLAG_*
> u8 bandwidth
> u8 mcs_nss[4]
> u8 coding
> u8 group_id
> u16 partial_aid
>
> ATM mac80211 can properly handle IEEE80211_RADIOTAP_VHT_KNOWN_GI,
> IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH and mcs_nss[0] (i.e single user).
>
> Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
> ---
> net/mac80211/status.c | 76 ++++++++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 63 insertions(+), 13 deletions(-)
>
> diff --git a/net/mac80211/status.c b/net/mac80211/status.c
> index 6ad4c14..1a1c7fd 100644
> --- a/net/mac80211/status.c
> +++ b/net/mac80211/status.c
> @@ -235,7 +235,8 @@ static int ieee80211_tx_radiotap_len(struct ieee80211_tx_info *info)
>
> /* IEEE80211_RADIOTAP_RATE rate */
> if (info->status.rates[0].idx >= 0 &&
> - !(info->status.rates[0].flags & IEEE80211_TX_RC_MCS))
> + !(info->status.rates[0].flags & (IEEE80211_TX_RC_MCS |
> + IEEE80211_TX_RC_VHT_MCS)))
> len += 2;
>
> /* IEEE80211_RADIOTAP_TX_FLAGS */
> @@ -244,16 +245,21 @@ static int ieee80211_tx_radiotap_len(struct ieee80211_tx_info *info)
> /* IEEE80211_RADIOTAP_DATA_RETRIES */
> len += 1;
>
> - /* IEEE80211_TX_RC_MCS */
> - if (info->status.rates[0].idx >= 0 &&
> - info->status.rates[0].flags & IEEE80211_TX_RC_MCS)
> - len += 3;
> + /* IEEE80211_RADIOTAP_MCS
> + * IEEE80211_RADIOTAP_VHT */
> + if (info->status.rates[0].idx >= 0) {
> + if (info->status.rates[0].flags & IEEE80211_TX_RC_MCS)
> + len += 3;
> + else if (info->status.rates[0].flags & IEEE80211_TX_RC_VHT_MCS)
> + len += ALIGN(len, 2) + 12;
The '+' is a typo, should be
len = ALIGN(len, 2) + 12;
--
Karl
^ permalink raw reply
* Re: [PATCH 35/50] media: usb: cx231xx: spin_lock in complete() cleanup
From: Ming Lei @ 2013-07-27 9:34 UTC (permalink / raw)
To: Hans Verkuil
Cc: Greg Kroah-Hartman, linux-usb, Oliver Neukum, Alan Stern,
linux-input, linux-bluetooth, netdev, linux-wireless, linux-media,
alsa-devel, Mauro Carvalho Chehab, Hans Verkuil
In-Reply-To: <51F2878E.90705@xs4all.nl>
On Fri, Jul 26, 2013 at 10:28 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
>
> On 07/11/2013 11:05 AM, Ming Lei wrote:
>> Complete() will be run with interrupt enabled, so change to
>> spin_lock_irqsave().
>>
>> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
>> Cc: Hans Verkuil <hans.verkuil@cisco.com>
>> Cc: linux-media@vger.kernel.org
>> Signed-off-by: Ming Lei <ming.lei@canonical.com>
>> ---
>> drivers/media/usb/cx231xx/cx231xx-audio.c | 6 ++++++
>> drivers/media/usb/cx231xx/cx231xx-core.c | 10 ++++++----
>> drivers/media/usb/cx231xx/cx231xx-vbi.c | 5 +++--
>> 3 files changed, 15 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-audio.c b/drivers/media/usb/cx231xx/cx231xx-audio.c
>> index 81a1d97..58c1b5c 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-audio.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-audio.c
>> @@ -136,6 +136,7 @@ static void cx231xx_audio_isocirq(struct urb *urb)
>> stride = runtime->frame_bits >> 3;
>>
>> for (i = 0; i < urb->number_of_packets; i++) {
>> + unsigned long flags;
>> int length = urb->iso_frame_desc[i].actual_length /
>> stride;
>> cp = (unsigned char *)urb->transfer_buffer +
>> @@ -158,6 +159,7 @@ static void cx231xx_audio_isocirq(struct urb *urb)
>> length * stride);
>> }
>>
>> + local_irq_save(flags);
>> snd_pcm_stream_lock(substream);
>
> Can't you use snd_pcm_stream_lock_irqsave here?
Sure, that is already in my mind, :-)
> Ditto for the other media drivers where this happens: em28xx and tlg2300.
Yes.
>
> I've reviewed the media driver changes and they look OK to me, so if
> my comment above is fixed, then I can merge them for 3.12. Or are these
> changes required for 3.11?
These are for 3.12.
I will send out v2 next week, and thanks for your review.
Thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH v2] mac80211: report some VHT radiotap infos for tx status
From: Karl Beldan @ 2013-07-27 9:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Karl Beldan
From: Karl Beldan <karl.beldan@rivierawaves.com>
The radiotap VHT info is 12 bytes (required to be aligned on 2) :
u16 known - IEEE80211_RADIOTAP_VHT_KNOWN_*
u8 flags - IEEE80211_RADIOTAP_VHT_FLAG_*
u8 bandwidth
u8 mcs_nss[4]
u8 coding
u8 group_id
u16 partial_aid
ATM mac80211 can handle IEEE80211_RADIOTAP_VHT_KNOWN_{GI,BANDWIDTH} and
mcs_nss[0] (i.e single user) in simple cases.
This is more a placeholder to let sniffers give more clues for VHT,
since we don't have yet the proper infrastructure/conventions
in mac80211 for complete feedback (e.g consider dynamic BW).
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
---
net/mac80211/status.c | 76 ++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 63 insertions(+), 13 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 6ad4c14..40d0523 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -235,7 +235,8 @@ static int ieee80211_tx_radiotap_len(struct ieee80211_tx_info *info)
/* IEEE80211_RADIOTAP_RATE rate */
if (info->status.rates[0].idx >= 0 &&
- !(info->status.rates[0].flags & IEEE80211_TX_RC_MCS))
+ !(info->status.rates[0].flags & (IEEE80211_TX_RC_MCS |
+ IEEE80211_TX_RC_VHT_MCS)))
len += 2;
/* IEEE80211_RADIOTAP_TX_FLAGS */
@@ -244,16 +245,21 @@ static int ieee80211_tx_radiotap_len(struct ieee80211_tx_info *info)
/* IEEE80211_RADIOTAP_DATA_RETRIES */
len += 1;
- /* IEEE80211_TX_RC_MCS */
- if (info->status.rates[0].idx >= 0 &&
- info->status.rates[0].flags & IEEE80211_TX_RC_MCS)
- len += 3;
+ /* IEEE80211_RADIOTAP_MCS
+ * IEEE80211_RADIOTAP_VHT */
+ if (info->status.rates[0].idx >= 0) {
+ if (info->status.rates[0].flags & IEEE80211_TX_RC_MCS)
+ len += 3;
+ else if (info->status.rates[0].flags & IEEE80211_TX_RC_VHT_MCS)
+ len = ALIGN(len, 2) + 12;
+ }
return len;
}
static void
-ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band *sband,
+ieee80211_add_tx_radiotap_header(struct ieee80211_local *local,
+ struct ieee80211_supported_band *sband,
struct sk_buff *skb, int retry_count,
int rtap_len, int shift)
{
@@ -280,7 +286,8 @@ ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band *sband,
/* IEEE80211_RADIOTAP_RATE */
if (info->status.rates[0].idx >= 0 &&
- !(info->status.rates[0].flags & IEEE80211_TX_RC_MCS)) {
+ !(info->status.rates[0].flags & (IEEE80211_TX_RC_MCS |
+ IEEE80211_TX_RC_VHT_MCS))) {
u16 rate;
rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_RATE);
@@ -310,9 +317,12 @@ ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band *sband,
*pos = retry_count;
pos++;
- /* IEEE80211_TX_RC_MCS */
- if (info->status.rates[0].idx >= 0 &&
- info->status.rates[0].flags & IEEE80211_TX_RC_MCS) {
+ if (info->status.rates[0].idx < 0)
+ return;
+
+ /* IEEE80211_RADIOTAP_MCS
+ * IEEE80211_RADIOTAP_VHT */
+ if (info->status.rates[0].flags & IEEE80211_TX_RC_MCS) {
rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS);
pos[0] = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
IEEE80211_RADIOTAP_MCS_HAVE_GI |
@@ -325,8 +335,48 @@ ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band *sband,
pos[1] |= IEEE80211_RADIOTAP_MCS_FMT_GF;
pos[2] = info->status.rates[0].idx;
pos += 3;
- }
+ } else if (info->status.rates[0].flags & IEEE80211_TX_RC_VHT_MCS) {
+ u16 known = local->hw.radiotap_vht_details &
+ (IEEE80211_RADIOTAP_VHT_KNOWN_GI |
+ IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH);
+
+ rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_VHT);
+
+ /* required alignment from rthdr */
+ pos = (u8 *)rthdr + ALIGN(pos - (u8 *)rthdr, 2);
+ /* u16 known - IEEE80211_RADIOTAP_VHT_KNOWN_* */
+ put_unaligned_le16(known, pos);
+ pos += 2;
+
+ /* u8 flags - IEEE80211_RADIOTAP_VHT_FLAG_* */
+ if (info->status.rates[0].flags & IEEE80211_TX_RC_SHORT_GI)
+ *pos |= IEEE80211_RADIOTAP_VHT_FLAG_SGI;
+ pos++;
+
+ /* u8 bandwidth */
+ if (info->status.rates[0].flags & IEEE80211_TX_RC_40_MHZ_WIDTH)
+ *pos = 1;
+ else if (info->status.rates[0].flags & IEEE80211_TX_RC_80_MHZ_WIDTH)
+ *pos = 4;
+ else if (info->status.rates[0].flags & IEEE80211_TX_RC_160_MHZ_WIDTH)
+ *pos = 11;
+ else /* IEEE80211_TX_RC_{20_MHZ_WIDTH,FIXME:DUP_DATA} */
+ *pos = 0;
+ pos++;
+
+ /* u8 mcs_nss[4] */
+ *pos = (ieee80211_rate_get_vht_mcs(&info->status.rates[0]) << 4) |
+ ieee80211_rate_get_vht_nss(&info->status.rates[0]);
+ pos += 4;
+
+ /* u8 coding */
+ pos++;
+ /* u8 group_id */
+ pos++;
+ /* u16 partial_aid */
+ pos += 2;
+ }
}
static void ieee80211_report_used_skb(struct ieee80211_local *local,
@@ -631,8 +681,8 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
dev_kfree_skb(skb);
return;
}
- ieee80211_add_tx_radiotap_header(sband, skb, retry_count, rtap_len,
- shift);
+ ieee80211_add_tx_radiotap_header(local, sband, skb, retry_count,
+ rtap_len, shift);
/* XXX: is this sufficient for BPF? */
skb_set_mac_header(skb, 0);
--
1.7.9.dirty
^ permalink raw reply related
* unable to unblock Bluetooth
From: Tomas Pospisek @ 2013-07-27 13:45 UTC (permalink / raw)
To: linux-wireless
Hello
I am not able to unblock Bluetooth:
# rfkill unblock all
# rfkill list 4
4: hp-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
The Bluetooth layer remains "Soft blocked".
My system looks like this:
- Linux: 3.11-rc1
- Userspace: Debian wheezy
- rfkill: 0.5
- HW: HP dv7 6130ez
- Bluetooth probably provided by:
# lspci
...
0d:00.0 Network controller: Ralink corp. RT5390
[802.11 b/g/n 1T1R G-band PCI Express Single Chip]
Kernel logs show no trace of a problem:
Bluetooth: Core ver 2.16
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: BNEP socket layer initialized
I had to provide some firware in order for the Bluetooth device to show
up in rfkill. I copied those firmware blobs over from Debian's
"firmware-ralink" package. It must be one of these:
rt2661.bin
rtl_nic
rtl_nic/rtl8168f-1.fw
rtl_nic/rtl8168e-1.fw
rtl_nic/rtl8168f-2.fw
rtl_nic/rtl8168e-3.fw
rtl_nic/rtl8168d-2.fw
rtl_nic/rtl8168e-2.fw
rtl_nic/rtl8105e-1.fw
rtl_nic/rtl8168d-1.fw
RTL8192SU
RTL8192SU/rtl8192sfw.bin
rt2561.bin
rt2870.bin
rt2860.bin
rt73.bin
rt3070.bin
rtlwifi
rtlwifi/rtl8192cufw.bin
rtlwifi/rtl8192cfwU.bin
rtlwifi/rtl8192cfw.bin
rtlwifi/rtl8192cfwU_B.bin
rtlwifi/rtl8192sefw.bin
rtlwifi/rtl8192defw.bin
rtlwifi/rtl8712u.bin
rt3071.bin
rt3090.bin
rt2561s.bin
RTL8192E
RTL8192E/main.img
RTL8192E/boot.img
RTL8192E/data.img
Additional possibly useful info:
# lsmod |grep blue
bluetooth 169854 10 bnep,rfcomm
rfkill 19242 6 cfg80211,hp_wmi,bluetooth
crc16 12343 2 ext4,bluetooth
What can I do to unblock the Bluetooth?
Thank you,
*t
^ permalink raw reply
* Re: [rt2x00-users] [NETWORKING DRIVERS RT2X00] please add support for Asus PCE-N53 (0x1814, 0x5592)
From: Stanislaw Gruszka @ 2013-07-27 16:46 UTC (permalink / raw)
To: Xose Vazquez Perez
Cc: treeve, linux-wireless, users@rt2x00.serialmonkey.com,
Jacob Oursland
In-Reply-To: <51EE8B74.8080206@gmail.com>
On Tue, Jul 23, 2013 at 03:56:04PM +0200, Xose Vazquez Perez wrote:
> Treeve Jelbert wrote:
>
> > linux-3.10.0 does not support device (0x1814, 0x5592) Asus PCE-N53 which I
> > would like to use on with 5GHz network.
> >
> > #lspci
> > 02:00.0 Network controller: Ralink corp. Device 5592
> > Subsystem: ASUSTeK Computer Inc. Device 851a
> >
> > # lspci -d :5592 -nn
> > 02:00.0 Network controller [0280]: Ralink corp. Device [1814:5592]
>
> RT5592 devices are still unsupported by rt2x00 drivers.
> Stanislaw Gruszka <stf_xl@wp.pl> was working on it.
I did not make any progress :-( I did some tracing using mmiotrace
to compare with vendor driver, but still did not find difference,
which couse rt2x00 do not work on that adapter.
Stanislaw
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Christian Lamparter @ 2013-07-27 21:59 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee, USB list
In-Reply-To: <51EFAE83.7010902@rempel-privat.de>
On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote:
> Am 23.07.2013 20:26, schrieb Christian Lamparter:
> > On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
> >> Am 22.07.2013 23:23, schrieb Christian Lamparter:
> >>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
> >>>> Am 22.07.2013 21:54, schrieb Christian Lamparter:
> >>>>> Hello!
> >>>>>
> >>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> >>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> >>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> >>>>>> accidentally discovered that 9170 have it too. Are there any issue with
> >>>>>> usb-suspend + xhci controllers by you? Did you some how specially
> >>>>>> handled it?
> >>>>>
> >>>>> No, I haven't heard any complains about xhci + suspend. In fact,
> >>>>> it's working fine with the NEC xhci I have. I also have a AR9271
> >>>>> and AR7010, so if you want I could try if they survive a suspend
> >>>>> +resume cycle when attached.
> >>>>>
> >>>>> But, I do have a bug-report from someone else who has/had? problems
> >>>>> with carl9170 and xhci. If you want, you can get the details from:
> >>>>> "carl9170 A-MPDU transmit problem":
> >>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
> >>>>>
> >>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> >>>>> affected, but I don't know about Haswell):
> >>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
> >>>>
> >>>> Same situation is here - i have problem on Ivy Bridge.
> >>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
> >>> and AMD's new A6-1450 Temash and both xhci work. So I can't
> >>> do any proper comparisons like you.)
> >>>
> >>>> Steps to reproduce:
> >>>> - plug adapter. Module and firmware will be loaded
> >>>> - make sure usb autosupend is enabled. By default it is not! Use
> >>>> powertop or directly sysfs to enable autosuspend for this device
> >>>> - rmmod .... and wait some seconds until adapter is suspended and then
> >>>> modprobe ath9k_htc
> >>
> >>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
> >>>> will report wrong size.. bigger as FIFO can handle. And only first ~40
> >>>> readet bytes will be actually OK.. all the rest of packet will be trashed.
> >>>
> >>> This is what happens with a WN721 (ar9271):
> >>>
> >>> [17619.597905] usbcore: deregistering interface driver ath9k_htc
> >>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
> >>> [17619.679602] ath9k_htc: Driver unloaded
> >>> <suspend>
> >>>
> >>> <resume>
> >>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
> >>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
> >>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
> >>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
> >>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
> >>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
> >>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
> >>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
> >>> [17667.573873] usbcore: registered new interface driver ath9k_htc
> >>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> >>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
> >>>
> >>> The driver loads, but there's no "wlanX" interface, no phyX interface
> >>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
> >>
> >> So, it is exactly this bug.
> >> After firmware was loaded ath9k trying to set some registers. Since
> >> command buffer is trashed it will write some nonsense to registers and
> >> some times in wrong to wrong addresses. I have some patches to do crc
> >> check of commands, to easy detect corrupted ones.
> >>
> >> You reproduced it on NEC xhci? Is it possible to reproduce it in
> >> carl9170?
> >
> > Ok: That's dmesg of your scenario:
> >
> > [ 809.995966] usbcore: deregistering interface driver carl9170
> > <suspend>
> >
> > <resume>
> > [ 826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
> > [ 826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
> > [ 826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
> > [ 826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
> > [ 826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
> > [ 826.432257] usbcore: registered new interface driver carl9170
> > [ 826.433717] usb 2-2: driver API: 1.9.8 2013-03-23 [1-1]
> > ...
> > [ 826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'
> >
> > carl9170 is able to recover and the stick is working after autosuspend cycle.
>
> Thank you for your tests. USB configuration and handlers look similar on
> this two firmwares. May be problem is not in FUSB200 and it is clock
> related issue so carl9170 do not need reset. - I don't know :(
>
> Can you please test this branch:
> https://github.com/olerem/open-ath9k-htc-firmware/commits/next
> There is a workaround to reset adapter, right after this bug is
> detected. It is really dirty hack, but currently i do not know how to
> fix this bug on xhci or on ath9k-htc side.
>
Is it still Saturday?
Anyway, I tried the -next branch.
commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
Author: Oleksij Rempel <linux@rempel-privat.de>
Date: Wed Jul 24 10:26:18 2013 +0200
k2_fw_usb_api: workaround for EP4 bug.
but still, the device won't show up after autosuspend.
regards,
Chr
^ permalink raw reply
* Re: [PATCH 3.11] genetlink: release cb_lock before requesting additional module
From: David Miller @ 2013-07-28 5:20 UTC (permalink / raw)
To: pshelar
Cc: sgruszka, linux-wireless, linville, netdev, tgraf, shemminger,
rjones, marcel, jlayton
In-Reply-To: <CALnjE+rcMoFkDPSQbD7VKvv2rYzKKEYcARtBH5y_A+ngrLbAzA@mail.gmail.com>
From: Pravin Shelar <pshelar@nicira.com>
Date: Fri, 26 Jul 2013 10:08:25 -0700
> On Fri, Jul 26, 2013 at 2:00 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> Requesting external module with cb_lock taken can result in
>> the deadlock like showed below:
...
>> Problem start to happen after adding net-pf-16-proto-16-family-nl80211
>> alias name to cfg80211 module by below commit (though that commit
>> itself is perfectly fine):
>>
>> commit fb4e156886ce6e8309e912d8b370d192330d19d3
>> Author: Marcel Holtmann <marcel@holtmann.org>
>> Date: Sun Apr 28 16:22:06 2013 -0700
>>
>> nl80211: Add generic netlink module alias for cfg80211/nl80211
>>
>> Reported-and-tested-by: Jeff Layton <jlayton@redhat.com>
>> Reported-by: Richard W.M. Jones <rjones@redhat.com>
>> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
...
> This is genl issue and it was introduced by commit def3117493eafd
> (genl: Allow concurrent genl callbacks.).
>
> Reviewed-by: Pravin B Shelar <pshelar@nicira.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-07-28 5:50 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <5176750.ryksn4nuMW@blech>
Am 27.07.2013 23:59, schrieb Christian Lamparter:
> On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote:
>> Am 23.07.2013 20:26, schrieb Christian Lamparter:
>>> On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
>>>> Am 22.07.2013 23:23, schrieb Christian Lamparter:
>>>>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
>>>>>> Am 22.07.2013 21:54, schrieb Christian Lamparter:
>>>>>>> Hello!
>>>>>>>
>>>>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
>>>>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
>>>>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
>>>>>>>> accidentally discovered that 9170 have it too. Are there any issue with
>>>>>>>> usb-suspend + xhci controllers by you? Did you some how specially
>>>>>>>> handled it?
>>>>>>>
>>>>>>> No, I haven't heard any complains about xhci + suspend. In fact,
>>>>>>> it's working fine with the NEC xhci I have. I also have a AR9271
>>>>>>> and AR7010, so if you want I could try if they survive a suspend
>>>>>>> +resume cycle when attached.
>>>>>>>
>>>>>>> But, I do have a bug-report from someone else who has/had? problems
>>>>>>> with carl9170 and xhci. If you want, you can get the details from:
>>>>>>> "carl9170 A-MPDU transmit problem":
>>>>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
>>>>>>>
>>>>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
>>>>>>> affected, but I don't know about Haswell):
>>>>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
>>>>>>
>>>>>> Same situation is here - i have problem on Ivy Bridge.
>>>>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
>>>>> and AMD's new A6-1450 Temash and both xhci work. So I can't
>>>>> do any proper comparisons like you.)
>>>>>
>>>>>> Steps to reproduce:
>>>>>> - plug adapter. Module and firmware will be loaded
>>>>>> - make sure usb autosupend is enabled. By default it is not! Use
>>>>>> powertop or directly sysfs to enable autosuspend for this device
>>>>>> - rmmod .... and wait some seconds until adapter is suspended and then
>>>>>> modprobe ath9k_htc
>>>>
>>>>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
>>>>>> will report wrong size.. bigger as FIFO can handle. And only first ~40
>>>>>> readet bytes will be actually OK.. all the rest of packet will be trashed.
>>>>>
>>>>> This is what happens with a WN721 (ar9271):
>>>>>
>>>>> [17619.597905] usbcore: deregistering interface driver ath9k_htc
>>>>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
>>>>> [17619.679602] ath9k_htc: Driver unloaded
>>>>> <suspend>
>>>>>
>>>>> <resume>
>>>>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
>>>>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
>>>>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
>>>>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
>>>>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
>>>>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
>>>>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
>>>>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
>>>>> [17667.573873] usbcore: registered new interface driver ath9k_htc
>>>>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
>>>>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
>>>>>
>>>>> The driver loads, but there's no "wlanX" interface, no phyX interface
>>>>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
>>>>
>>>> So, it is exactly this bug.
>>>> After firmware was loaded ath9k trying to set some registers. Since
>>>> command buffer is trashed it will write some nonsense to registers and
>>>> some times in wrong to wrong addresses. I have some patches to do crc
>>>> check of commands, to easy detect corrupted ones.
>>>>
>>>> You reproduced it on NEC xhci? Is it possible to reproduce it in
>>>> carl9170?
>>>
>>> Ok: That's dmesg of your scenario:
>>>
>>> [ 809.995966] usbcore: deregistering interface driver carl9170
>>> <suspend>
>>>
>>> <resume>
>>> [ 826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
>>> [ 826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
>>> [ 826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
>>> [ 826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
>>> [ 826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
>>> [ 826.432257] usbcore: registered new interface driver carl9170
>>> [ 826.433717] usb 2-2: driver API: 1.9.8 2013-03-23 [1-1]
>>> ...
>>> [ 826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'
>>>
>>> carl9170 is able to recover and the stick is working after autosuspend cycle.
>>
>> Thank you for your tests. USB configuration and handlers look similar on
>> this two firmwares. May be problem is not in FUSB200 and it is clock
>> related issue so carl9170 do not need reset. - I don't know :(
>>
>> Can you please test this branch:
>> https://github.com/olerem/open-ath9k-htc-firmware/commits/next
>> There is a workaround to reset adapter, right after this bug is
>> detected. It is really dirty hack, but currently i do not know how to
>> fix this bug on xhci or on ath9k-htc side.
>>
> Is it still Saturday?
>
> Anyway, I tried the -next branch.
>
> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
> Author: Oleksij Rempel <linux@rempel-privat.de>
> Date: Wed Jul 24 10:26:18 2013 +0200
>
> k2_fw_usb_api: workaround for EP4 bug.
>
> but still, the device won't show up after autosuspend.
Hm... firmware probably didn't rebooted before suspend. Did interface
was up, before autosuspend? If no, you need latest wireles-testing -
there are patches to handle this issue. Or just make "ifconfig wlan1 up"
before rmmod.
If it was up... then i would need last log messages from firmware.. If
there is some way to attach to uart pins on it.
--
Regards,
Oleksij
^ permalink raw reply
* (no subject)
From: piuvatsa @ 2013-07-28 14:21 UTC (permalink / raw)
To: linux-wireless
i am using debian 7.1 whezzy but there is a problem in the wi-fi blooth
is working but wi-fi is not showing it may be due to driver problem. I
am a Dell xps user plz help me to solve out this problem
^ permalink raw reply
* Re:
From: Tomas Pospisek @ 2013-07-28 9:49 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1375021308.7557.3.camel@piu-xps>
Am 28.07.2013 16:21, schrieb piuvatsa:
> i am using debian 7.1 whezzy but there is a problem in the wi-fi blooth
> is working but wi-fi is not showing it may be due to driver problem. I
> am a Dell xps user plz help me to solve out this problem
You may want to have a look at these:
http://catb.org/~esr/faqs/smart-questions.html#writewell
http://catb.org/~esr/faqs/smart-questions.html#beprecise
*t
^ permalink raw reply
* [PATCH 3.11] rt2x00: fix stop queue
From: stf_xl @ 2013-07-28 11:17 UTC (permalink / raw)
To: linux-wireless; +Cc: users, Stanislaw Gruszka
From: Stanislaw Gruszka <stf_xl@wp.pl>
Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.
To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.
Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.
Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
---
drivers/net/wireless/rt2x00/rt2x00queue.c | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index e571298..8c1de0f 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -936,13 +936,8 @@ void rt2x00queue_index_inc(struct queue_entry *entry, enum queue_index index)
spin_unlock_irqrestore(&queue->index_lock, irqflags);
}
-void rt2x00queue_pause_queue(struct data_queue *queue)
+void rt2x00queue_pause_queue_nocheck(struct data_queue *queue)
{
- if (!test_bit(DEVICE_STATE_PRESENT, &queue->rt2x00dev->flags) ||
- !test_bit(QUEUE_STARTED, &queue->flags) ||
- test_and_set_bit(QUEUE_PAUSED, &queue->flags))
- return;
-
switch (queue->qid) {
case QID_AC_VO:
case QID_AC_VI:
@@ -958,6 +953,15 @@ void rt2x00queue_pause_queue(struct data_queue *queue)
break;
}
}
+void rt2x00queue_pause_queue(struct data_queue *queue)
+{
+ if (!test_bit(DEVICE_STATE_PRESENT, &queue->rt2x00dev->flags) ||
+ !test_bit(QUEUE_STARTED, &queue->flags) ||
+ test_and_set_bit(QUEUE_PAUSED, &queue->flags))
+ return;
+
+ rt2x00queue_pause_queue_nocheck(queue);
+}
EXPORT_SYMBOL_GPL(rt2x00queue_pause_queue);
void rt2x00queue_unpause_queue(struct data_queue *queue)
@@ -1019,7 +1023,7 @@ void rt2x00queue_stop_queue(struct data_queue *queue)
return;
}
- rt2x00queue_pause_queue(queue);
+ rt2x00queue_pause_queue_nocheck(queue);
queue->rt2x00dev->ops->lib->stop_queue(queue);
--
1.7.4.4
^ permalink raw reply related
* Re: FUSB200 xhci issue
From: Christian Lamparter @ 2013-07-28 11:38 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless
In-Reply-To: <51F4B128.3010901@rempel-privat.de>
On Sunday 28 July 2013 07:50:32 Oleksij Rempel wrote:
> Am 27.07.2013 23:59, schrieb Christian Lamparter:
> > On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote:
> >> Am 23.07.2013 20:26, schrieb Christian Lamparter:
> >>> On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
> >>>> Am 22.07.2013 23:23, schrieb Christian Lamparter:
> >>>>> On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
> >>>>>> Am 22.07.2013 21:54, schrieb Christian Lamparter:
> >>>>>>> Hello!
> >>>>>>>
> >>>>>>> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> >>>>>>>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> >>>>>>>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> >>>>>>>> accidentally discovered that 9170 have it too. Are there any issue with
> >>>>>>>> usb-suspend + xhci controllers by you? Did you some how specially
> >>>>>>>> handled it?
> >>>>>>>
> >>>>>>> No, I haven't heard any complains about xhci + suspend. In fact,
> >>>>>>> it's working fine with the NEC xhci I have. I also have a AR9271
> >>>>>>> and AR7010, so if you want I could try if they survive a suspend
> >>>>>>> +resume cycle when attached.
> >>>>>>>
> >>>>>>> But, I do have a bug-report from someone else who has/had? problems
> >>>>>>> with carl9170 and xhci. If you want, you can get the details from:
> >>>>>>> "carl9170 A-MPDU transmit problem":
> >>>>>>> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
> >>>>>>>
> >>>>>>> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> >>>>>>> affected, but I don't know about Haswell):
> >>>>>>> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
> >>>>>>
> >>>>>> Same situation is here - i have problem on Ivy Bridge.
> >>>>> (Note: I don't have any Ivy Bridge system. Just Sandy Bridge
> >>>>> and AMD's new A6-1450 Temash and both xhci work. So I can't
> >>>>> do any proper comparisons like you.)
> >>>>>
> >>>>>> Steps to reproduce:
> >>>>>> - plug adapter. Module and firmware will be loaded
> >>>>>> - make sure usb autosupend is enabled. By default it is not! Use
> >>>>>> powertop or directly sysfs to enable autosuspend for this device
> >>>>>> - rmmod .... and wait some seconds until adapter is suspended and then
> >>>>>> modprobe ath9k_htc
> >>>>
> >>>>>> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
> >>>>>> will report wrong size.. bigger as FIFO can handle. And only first ~40
> >>>>>> readet bytes will be actually OK.. all the rest of packet will be trashed.
> >>>>>
> >>>>> This is what happens with a WN721 (ar9271):
> >>>>>
> >>>>> [17619.597905] usbcore: deregistering interface driver ath9k_htc
> >>>>> [17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
> >>>>> [17619.679602] ath9k_htc: Driver unloaded
> >>>>> <suspend>
> >>>>>
> >>>>> <resume>
> >>>>> [17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
> >>>>> [17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
> >>>>> [17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
> >>>>> [17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
> >>>>> [17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
> >>>>> [17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
> >>>>> [17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
> >>>>> [17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
> >>>>> [17667.573873] usbcore: registered new interface driver ath9k_htc
> >>>>> [17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
> >>>>> [17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
> >>>>>
> >>>>> The driver loads, but there's no "wlanX" interface, no phyX interface
> >>>>> and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
> >>>>
> >>>> So, it is exactly this bug.
> >>>> After firmware was loaded ath9k trying to set some registers. Since
> >>>> command buffer is trashed it will write some nonsense to registers and
> >>>> some times in wrong to wrong addresses. I have some patches to do crc
> >>>> check of commands, to easy detect corrupted ones.
> >>>>
> >>>> You reproduced it on NEC xhci? Is it possible to reproduce it in
> >>>> carl9170?
> >>>
> >>> Ok: That's dmesg of your scenario:
> >>>
> >>> [ 809.995966] usbcore: deregistering interface driver carl9170
> >>> <suspend>
> >>>
> >>> <resume>
> >>> [ 826.365596] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
> >>> [ 826.431154] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b900
> >>> [ 826.431159] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b940
> >>> [ 826.431162] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b980
> >>> [ 826.431164] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88045af2b9c0
> >>> [ 826.432257] usbcore: registered new interface driver carl9170
> >>> [ 826.433717] usb 2-2: driver API: 1.9.8 2013-03-23 [1-1]
> >>> ...
> >>> [ 826.816110] usb 2-2: Atheros AR9170 is registered as 'phy3'
> >>>
> >>> carl9170 is able to recover and the stick is working after autosuspend cycle.
> >>
> >> Thank you for your tests. USB configuration and handlers look similar on
> >> this two firmwares. May be problem is not in FUSB200 and it is clock
> >> related issue so carl9170 do not need reset. - I don't know :(
> >>
> >> Can you please test this branch:
> >> https://github.com/olerem/open-ath9k-htc-firmware/commits/next
> >> There is a workaround to reset adapter, right after this bug is
> >> detected. It is really dirty hack, but currently i do not know how to
> >> fix this bug on xhci or on ath9k-htc side.
> >>
> > Is it still Saturday?
> >
> > Anyway, I tried the -next branch.
> >
> > commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
> > Author: Oleksij Rempel <linux@rempel-privat.de>
> > Date: Wed Jul 24 10:26:18 2013 +0200
> >
> > k2_fw_usb_api: workaround for EP4 bug.
> >
> > but still, the device won't show up after autosuspend.
>
> Hm... firmware probably didn't rebooted before suspend. Did interface
> was up, before autosuspend? If no, you need latest wireles-testing -
> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
> before rmmod.
Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
had the patch "ath9k_htc: reboot firmwware if it was loaded").
Furthermore, I did the same test with one of the ehci-only ports
and it worked. Both, devices (one had a AR7015, the other a AR9271)
came back after autosuspend there.
> then i would need last log messages from firmware.. If there is
> some way to attach to uart pins on it.
Sorry, I can't really help you there as I don't have the
necessary tools. But I would be happy to test patches.
Regards,
Chr
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-07-28 12:12 UTC (permalink / raw)
To: Christian Lamparter
Cc: linux-wireless, Sarah Sharp, USB list, Seth Forshee, ath9k_htc_fw
In-Reply-To: <201307281338.39157.chunkeey@googlemail.com>
Am 28.07.2013 13:38, schrieb Christian Lamparter:
>>>
>>> Anyway, I tried the -next branch.
>>>
>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
>>> Author: Oleksij Rempel <linux@rempel-privat.de>
>>> Date: Wed Jul 24 10:26:18 2013 +0200
>>>
>>> k2_fw_usb_api: workaround for EP4 bug.
>>>
>>> but still, the device won't show up after autosuspend.
>>
>> Hm... firmware probably didn't rebooted before suspend. Did interface
>> was up, before autosuspend? If no, you need latest wireles-testing -
>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
>> before rmmod.
> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>
> Furthermore, I did the same test with one of the ehci-only ports
> and it worked. Both, devices (one had a AR7015, the other a AR9271)
> came back after autosuspend there.
Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
work here :( Suddenly i have no more ideas.
Sarah, it's your turn now.
--
Regards,
Oleksij
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-07-28 14:28 UTC (permalink / raw)
To: Christian Lamparter
Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless
In-Reply-To: <51F50AB7.3030204@rempel-privat.de>
Am 28.07.2013 14:12, schrieb Oleksij Rempel:
> Am 28.07.2013 13:38, schrieb Christian Lamparter:
>
>>>>
>>>> Anyway, I tried the -next branch.
>>>>
>>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
>>>> Author: Oleksij Rempel <linux@rempel-privat.de>
>>>> Date: Wed Jul 24 10:26:18 2013 +0200
>>>>
>>>> k2_fw_usb_api: workaround for EP4 bug.
>>>>
>>>> but still, the device won't show up after autosuspend.
>>>
>>> Hm... firmware probably didn't rebooted before suspend. Did interface
>>> was up, before autosuspend? If no, you need latest wireles-testing -
>>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
>>> before rmmod.
>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>>
>> Furthermore, I did the same test with one of the ehci-only ports
>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
>> came back after autosuspend there.
>
> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
> work here :( Suddenly i have no more ideas.
>
> Sarah, it's your turn now.
Christian,
can you please provide some more info about your xhci controller. I'll
try to get me same.
--
Regards,
Oleksij
^ permalink raw reply
* Re: unable to unblock Bluetooth
From: Pat Erley @ 2013-07-28 18:57 UTC (permalink / raw)
To: Tomas Pospisek; +Cc: linux-wireless
In-Reply-To: <51F3CEF7.4030200@sourcepole.ch>
On 07/27/2013 09:45 AM, Tomas Pospisek wrote:
> Hello
>
> I am not able to unblock Bluetooth:
>
> # rfkill unblock all
> # rfkill list 4
> 4: hp-bluetooth: Bluetooth
> Soft blocked: yes
> Hard blocked: no
>
> The Bluetooth layer remains "Soft blocked".
>
> My system looks like this:
>
> - Linux: 3.11-rc1
> - Userspace: Debian wheezy
> - rfkill: 0.5
> - HW: HP dv7 6130ez
> - Bluetooth probably provided by:
> # lspci
> ...
> 0d:00.0 Network controller: Ralink corp. RT5390
> [802.11 b/g/n 1T1R G-band PCI Express Single Chip]
>
> Kernel logs show no trace of a problem:
>
> Bluetooth: Core ver 2.16
> Bluetooth: HCI device and connection manager initialized
> Bluetooth: HCI socket layer initialized
> Bluetooth: L2CAP socket layer initialized
> Bluetooth: SCO socket layer initialized
> Bluetooth: RFCOMM TTY layer initialized
> Bluetooth: RFCOMM socket layer initialized
> Bluetooth: RFCOMM ver 1.11
> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> Bluetooth: BNEP filters: protocol multicast
> Bluetooth: BNEP socket layer initialized
>
> I had to provide some firware in order for the Bluetooth device to show
> up in rfkill. I copied those firmware blobs over from Debian's
> "firmware-ralink" package. It must be one of these:
>
> rt2661.bin
> rtl_nic
> rtl_nic/rtl8168f-1.fw
> rtl_nic/rtl8168e-1.fw
> rtl_nic/rtl8168f-2.fw
> rtl_nic/rtl8168e-3.fw
> rtl_nic/rtl8168d-2.fw
> rtl_nic/rtl8168e-2.fw
> rtl_nic/rtl8105e-1.fw
> rtl_nic/rtl8168d-1.fw
> RTL8192SU
> RTL8192SU/rtl8192sfw.bin
> rt2561.bin
> rt2870.bin
> rt2860.bin
> rt73.bin
> rt3070.bin
> rtlwifi
> rtlwifi/rtl8192cufw.bin
> rtlwifi/rtl8192cfwU.bin
> rtlwifi/rtl8192cfw.bin
> rtlwifi/rtl8192cfwU_B.bin
> rtlwifi/rtl8192sefw.bin
> rtlwifi/rtl8192defw.bin
> rtlwifi/rtl8712u.bin
> rt3071.bin
> rt3090.bin
> rt2561s.bin
> RTL8192E
> RTL8192E/main.img
> RTL8192E/boot.img
> RTL8192E/data.img
>
> Additional possibly useful info:
>
> # lsmod |grep blue
> bluetooth 169854 10 bnep,rfcomm
> rfkill 19242 6 cfg80211,hp_wmi,bluetooth
> crc16 12343 2 ext4,bluetooth
>
> What can I do to unblock the Bluetooth?
>
> Thank you,
> *t
lsusb might be useful here too. hp_wmi hooked into rfkill might mean
that hp-wmi is setting that soft block. Perhaps you have a keyboard
combo to unblock it?
Pat Erley
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Christian Lamparter @ 2013-07-28 20:41 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless
In-Reply-To: <51F52A89.4050506@rempel-privat.de>
On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
> > Am 28.07.2013 13:38, schrieb Christian Lamparter:
> >
> >>>>
> >>>> Anyway, I tried the -next branch.
> >>>>
> >>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
> >>>> Author: Oleksij Rempel <linux@rempel-privat.de>
> >>>> Date: Wed Jul 24 10:26:18 2013 +0200
> >>>>
> >>>> k2_fw_usb_api: workaround for EP4 bug.
> >>>>
> >>>> but still, the device won't show up after autosuspend.
> >>>
> >>> Hm... firmware probably didn't rebooted before suspend. Did interface
> >>> was up, before autosuspend? If no, you need latest wireles-testing -
> >>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
> >>> before rmmod.
> >> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
> >> had the patch "ath9k_htc: reboot firmwware if it was loaded").
> >>
> >> Furthermore, I did the same test with one of the ehci-only ports
> >> and it worked. Both, devices (one had a AR7015, the other a AR9271)
> >> came back after autosuspend there.
> >
> > Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
> > work here :( Suddenly i have no more ideas.
> >
> > Sarah, it's your turn now.
>
> Christian,
> can you please provide some more info about your xhci controller. I'll
> try to get me same.
Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
same setup will be difficult. However, since the uPD720200 was/is
very popular, it should be very easy to find one. [It's probably
on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
got a free 1x-pcie port you should be good.]
Here's the lspci summary:
19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
Subsystem: Hewlett-Packard Company Device [103c:1657]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: xhci_hcd
Regards,
Chr
^ permalink raw reply
* Re: unable to unblock Bluetooth
From: Tomas Pospisek @ 2013-07-28 21:01 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <51F569A6.5090800@erley.org>
Am 28.07.2013 20:57, schrieb Pat Erley:
> On 07/27/2013 09:45 AM, Tomas Pospisek wrote:
>> Hello
>>
>> I am not able to unblock Bluetooth:
>>
>> # rfkill unblock all
>> # rfkill list 4
>> 4: hp-bluetooth: Bluetooth
>> Soft blocked: yes
>> Hard blocked: no
>>
>> The Bluetooth layer remains "Soft blocked".
>>
>> My system looks like this:
>>
>> - Linux: 3.11-rc1
>> - Userspace: Debian wheezy
>> - rfkill: 0.5
>> - HW: HP dv7 6130ez
>> - Bluetooth probably provided by:
>> # lspci
>> ...
>> 0d:00.0 Network controller: Ralink corp. RT5390
>> [802.11 b/g/n 1T1R G-band PCI Express Single Chip]
>>
>> Kernel logs show no trace of a problem:
>>
>> Bluetooth: Core ver 2.16
>> Bluetooth: HCI device and connection manager initialized
>> Bluetooth: HCI socket layer initialized
>> Bluetooth: L2CAP socket layer initialized
>> Bluetooth: SCO socket layer initialized
>> Bluetooth: RFCOMM TTY layer initialized
>> Bluetooth: RFCOMM socket layer initialized
>> Bluetooth: RFCOMM ver 1.11
>> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>> Bluetooth: BNEP filters: protocol multicast
>> Bluetooth: BNEP socket layer initialized
>>
>> I had to provide some firware in order for the Bluetooth device to show
>> up in rfkill. I copied those firmware blobs over from Debian's
>> "firmware-ralink" package. It must be one of these:
>>
>> rt2661.bin
>> rtl_nic
>> rtl_nic/rtl8168f-1.fw
>> rtl_nic/rtl8168e-1.fw
>> rtl_nic/rtl8168f-2.fw
>> rtl_nic/rtl8168e-3.fw
>> rtl_nic/rtl8168d-2.fw
>> rtl_nic/rtl8168e-2.fw
>> rtl_nic/rtl8105e-1.fw
>> rtl_nic/rtl8168d-1.fw
>> RTL8192SU
>> RTL8192SU/rtl8192sfw.bin
>> rt2561.bin
>> rt2870.bin
>> rt2860.bin
>> rt73.bin
>> rt3070.bin
>> rtlwifi
>> rtlwifi/rtl8192cufw.bin
>> rtlwifi/rtl8192cfwU.bin
>> rtlwifi/rtl8192cfw.bin
>> rtlwifi/rtl8192cfwU_B.bin
>> rtlwifi/rtl8192sefw.bin
>> rtlwifi/rtl8192defw.bin
>> rtlwifi/rtl8712u.bin
>> rt3071.bin
>> rt3090.bin
>> rt2561s.bin
>> RTL8192E
>> RTL8192E/main.img
>> RTL8192E/boot.img
>> RTL8192E/data.img
>>
>> Additional possibly useful info:
>>
>> # lsmod |grep blue
>> bluetooth 169854 10 bnep,rfcomm
>> rfkill 19242 6 cfg80211,hp_wmi,bluetooth
>> crc16 12343 2 ext4,bluetooth
>>
>> What can I do to unblock the Bluetooth?
>
> lsusb might be useful here too. hp_wmi hooked into rfkill might mean
> that hp-wmi is setting that soft block. Perhaps you have a keyboard
> combo to unblock it?
Thanks Pat, there's only the "lighthouse" button, that I'm interpreting
as wifi on/off button. Other than that there doesn't seem to be any
"bluetooth" or related button.
As for:
# lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 138a:0018 Validity Sensors, Inc.
Bus 001 Device 004: ID 064e:e258 Suyin Corp.
"Validity Sensors" seems to be the fingerprint reader and "Suyin Corp."
seems to be the laptop camera.
I wrote Matthew Garrett the hp_wmi author, but haven heard back. I'm not
sure, maybe I shouldn't contact him directly or maybe he's just busy or
on holidays currently.
If anybody can point out to me what direction to take from here I'd be
very glad.
Thanks,
*t
*t
^ permalink raw reply
* [PATCH v2] ath10k: implement get_survey()
From: Michal Kazior @ 2013-07-29 7:08 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1374750412-5513-1-git-send-email-michal.kazior@tieto.com>
This implements a limited subset of what can be
reported in the survey dump.
This can be used for assessing approximate channel
load, e.g. for automatic channel selection.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
v2: Do not sum up channel time. Each time a
channel is visited stats for that channel are
overwritten. This makes the behaviour
more consistent with ath9k.
drivers/net/wireless/ath/ath10k/core.h | 6 +++
drivers/net/wireless/ath/ath10k/mac.c | 36 +++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 68 +++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi.h | 3 ++
4 files changed, 112 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 9f21ecb..e1cd1e7 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -38,6 +38,7 @@
#define ATH10K_SCAN_ID 0
#define WMI_READY_TIMEOUT (5 * HZ)
#define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ)
+#define ATH10K_NUM_CHANS 38
/* Antenna noise floor */
#define ATH10K_DEFAULT_NOISE_FLOOR -95
@@ -374,6 +375,11 @@ struct ath10k {
struct work_struct restart_work;
+ /* cycle count is reported twice for each visited channel during scan */
+ u32 survey_last_rx_clear_count;
+ u32 survey_last_cycle_count;
+ struct survey_info survey[ATH10K_NUM_CHANS];
+
#ifdef CONFIG_ATH10K_DEBUGFS
struct ath10k_debug debug;
#endif
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d0a7761..5d4ce96 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2934,6 +2934,41 @@ static void ath10k_restart_complete(struct ieee80211_hw *hw)
mutex_unlock(&ar->conf_mutex);
}
+static int ath10k_get_survey(struct ieee80211_hw *hw, int idx,
+ struct survey_info *survey)
+{
+ struct ath10k *ar = hw->priv;
+ struct ieee80211_supported_band *sband;
+ struct survey_info *ar_survey = &ar->survey[idx];
+ int ret = 0;
+
+ mutex_lock(&ar->conf_mutex);
+
+ sband = hw->wiphy->bands[IEEE80211_BAND_2GHZ];
+ if (sband && idx >= sband->n_channels) {
+ idx -= sband->n_channels;
+ sband = NULL;
+ }
+
+ if (!sband)
+ sband = hw->wiphy->bands[IEEE80211_BAND_5GHZ];
+
+ if (!sband || idx >= sband->n_channels) {
+ ret = -ENOENT;
+ goto exit;
+ }
+
+ spin_lock_bh(&ar->data_lock);
+ memcpy(survey, ar_survey, sizeof(*survey));
+ spin_unlock_bh(&ar->data_lock);
+
+ survey->channel = &sband->channels[idx];
+
+exit:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_tx,
.start = ath10k_start,
@@ -2955,6 +2990,7 @@ static const struct ieee80211_ops ath10k_ops = {
.flush = ath10k_flush,
.tx_last_beacon = ath10k_tx_last_beacon,
.restart_complete = ath10k_restart_complete,
+ .get_survey = ath10k_get_survey,
#ifdef CONFIG_PM
.suspend = ath10k_suspend,
.resume = ath10k_resume,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 5e42460..2150dc84 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -390,9 +390,75 @@ static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
return 0;
}
+static int freq_to_idx(struct ath10k *ar, int freq)
+{
+ struct ieee80211_supported_band *sband;
+ int band, ch, idx = 0;
+
+ for (band = IEEE80211_BAND_2GHZ; band < IEEE80211_NUM_BANDS; band++) {
+ sband = ar->hw->wiphy->bands[band];
+ if (!sband)
+ continue;
+
+ for (ch = 0; ch < sband->n_channels; ch++, idx++)
+ if (sband->channels[ch].center_freq == freq)
+ goto exit;
+ }
+
+exit:
+ return idx;
+}
+
static void ath10k_wmi_event_chan_info(struct ath10k *ar, struct sk_buff *skb)
{
- ath10k_dbg(ATH10K_DBG_WMI, "WMI_CHAN_INFO_EVENTID\n");
+ struct wmi_chan_info_event *ev;
+ int idx;
+
+ spin_lock_bh(&ar->data_lock);
+
+ ev = (struct wmi_chan_info_event *)skb->data;
+ ath10k_dbg(ATH10K_DBG_WMI,
+ "chan info: err_code:%d freq:%d cmd_flags:%d noise_floor:%d rx_clear_count:%d cycle_count:%d\n",
+ __le32_to_cpu(ev->err_code),
+ __le32_to_cpu(ev->freq),
+ __le32_to_cpu(ev->cmd_flags),
+ __le32_to_cpu(ev->noise_floor),
+ __le32_to_cpu(ev->rx_clear_count),
+ __le32_to_cpu(ev->cycle_count));
+
+ if (!ar->scan.in_progress) {
+ ath10k_warn("chan info event without a scan request?\n");
+ goto exit;
+ }
+
+ if (__le32_to_cpu(ev->cmd_flags) & WMI_CHAN_INFO_FLAG_COMPLETE) {
+ idx = freq_to_idx(ar, __le32_to_cpu(ev->freq));
+ if (idx >= ARRAY_SIZE(ar->survey)) {
+ ath10k_warn("chan info: invalid frequency %d (idx %d out of bounds)\n",
+ __le32_to_cpu(ev->freq), idx);
+ } else {
+ /* During scanning chan info is reported twice for each
+ * visited channel. The reported cycle count is global
+ * and per-channel cycle count must be calculated */
+
+ ar->survey[idx].channel_time = WMI_CHAN_INFO_MSEC(
+ __le32_to_cpu(ev->cycle_count) -
+ ar->survey_last_cycle_count);
+ ar->survey[idx].channel_time_rx = WMI_CHAN_INFO_MSEC(
+ __le32_to_cpu(ev->rx_clear_count) -
+ ar->survey_last_rx_clear_count);
+ ar->survey[idx].noise = __le32_to_cpu(ev->noise_floor);
+ ar->survey[idx].filled = SURVEY_INFO_CHANNEL_TIME |
+ SURVEY_INFO_CHANNEL_TIME_RX |
+ SURVEY_INFO_NOISE_DBM;
+ }
+ }
+
+ ar->survey_last_rx_clear_count = __le32_to_cpu(ev->rx_clear_count);
+ ar->survey_last_cycle_count = __le32_to_cpu(ev->cycle_count);
+
+exit:
+ spin_unlock_bh(&ar->data_lock);
}
static void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index da3b2bc..4acff47 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2931,6 +2931,9 @@ struct wmi_chan_info_event {
__le32 cycle_count;
} __packed;
+#define WMI_CHAN_INFO_FLAG_COMPLETE BIT(0)
+#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595) /* XXX: empirically extrapolated */
+
/* Beacon filter wmi command info */
#define BCN_FLT_MAX_SUPPORTED_IES 256
#define BCN_FLT_MAX_ELEMS_IE_LIST (BCN_FLT_MAX_SUPPORTED_IES / 32)
--
1.7.9.5
^ permalink raw reply related
* [RFC 0/3] introduce chan_time parameter to scan request
From: Michal Kazior @ 2013-07-29 8:39 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, ath10k, Michal Kazior
Hi,
This patchset adds a new scan parameter. It allows
specyfing for how long each channel should be
visited during scan.
I've tested this with ath9k (which doesn't have
hw_scan) and ath10k (does have hw_scan). It's not
super time-precise, but seems reasonable.
The main motivation behind this is to allow easier
ACS implementation in hostapd.
This could also perhaps be useful for spectral
scan and anyone interested in having ability to
tune scan times (e.g. very fast initial channel
scanning on mobile devices, long passive scans).
I'm wondering if it would be okay to set swscan
probe delay to 0 if chan_time is non-zero? Or does
probe delay need to be non-zero? Or maybe it
should also be configurable via a parameter?
Pozdrawiam / Best regards,
Michal Kazior.
Michal Kazior (3):
nl/cfg80211: add chan_time for scan request
mac80211: add support for scan chan_time parameter
ath10k: respect chan_time parameter in scan request
drivers/net/wireless/ath/ath10k/mac.c | 6 ++++++
include/net/cfg80211.h | 3 +++
include/uapi/linux/nl80211.h | 7 +++++++
net/mac80211/scan.c | 22 ++++++++++++++++++++--
net/wireless/nl80211.c | 4 ++++
5 files changed, 40 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [RFC 1/3] nl/cfg80211: add chan_time for scan request
From: Michal Kazior @ 2013-07-29 8:39 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, ath10k, Michal Kazior
In-Reply-To: <1375087158-22077-1-git-send-email-michal.kazior@tieto.com>
The new scan parameter allows user to specify how
long driver should remain on each scanned channel.
The default is to leave it up to driver to decide.
If specified it is preferred for driver to respect
this setting although it may ignore it if it can't
support it.
This can be useful to do very quick/slow scans
and/or gether survey data, e.g. for automatic
channel selection.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
include/net/cfg80211.h | 3 +++
include/uapi/linux/nl80211.h | 7 +++++++
net/wireless/nl80211.c | 4 ++++
3 files changed, 14 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index aeaf6df..2d46112 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1323,6 +1323,8 @@ struct cfg80211_ssid {
* @aborted: (internal) scan request was notified as aborted
* @notified: (internal) scan request was notified as done or aborted
* @no_cck: used to send probe requests at non CCK rate in 2GHz band
+ * @chan_time: how many msec driver should stay on each channel during scan.
+ * Setting 0 leaves the decision up to the driver.
*/
struct cfg80211_scan_request {
struct cfg80211_ssid *ssids;
@@ -1332,6 +1334,7 @@ struct cfg80211_scan_request {
const u8 *ie;
size_t ie_len;
u32 flags;
+ int chan_time;
u32 rates[IEEE80211_NUM_BANDS];
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index eb68735..4ea1d9b 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1469,6 +1469,11 @@ enum nl80211_commands {
*
* @NL80211_ATTR_COALESCE_RULE: Coalesce rule information.
*
+ * @NL80211_ATTR_SCAN_CHAN_TIME: Specifies how many msec should a driver spend
+ * on each channel during scanning. This is optional and the default is
+ * leave the decision up to the driver. This setting may, but preferrably
+ * shouldn't, be ignored by driver.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1771,6 +1776,8 @@ enum nl80211_attrs {
NL80211_ATTR_COALESCE_RULE,
+ NL80211_ATTR_SCAN_CHAN_TIME,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 03d4ef9..27a8fef 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5298,6 +5298,10 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
request->no_cck =
nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
+ if (info->attrs[NL80211_ATTR_SCAN_CHAN_TIME])
+ request->chan_time =
+ nla_get_u32(info->attrs[NL80211_ATTR_SCAN_CHAN_TIME]);
+
request->wdev = wdev;
request->wiphy = &rdev->wiphy;
request->scan_start = jiffies;
--
1.7.9.5
^ permalink raw reply related
* [RFC 2/3] mac80211: add support for scan chan_time parameter
From: Michal Kazior @ 2013-07-29 8:39 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, ath10k, Michal Kazior
In-Reply-To: <1375087158-22077-1-git-send-email-michal.kazior@tieto.com>
This allows mac80211-based drivers that support
hw_scan() to get chan_time paremter.
This also makes mac80211-based drivers that don't
support hw_scan() to respect the chan_time
parameter.
The effective minimum channel time for swscan
drivers is the probe delay. hw_scan drivers may
have their own limits.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
net/mac80211/scan.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 08afe74..e8b1aca 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -443,7 +443,18 @@ static void ieee80211_scan_state_send_probe(struct ieee80211_local *local,
* After sending probe requests, wait for probe responses
* on the channel.
*/
- *next_delay = IEEE80211_CHANNEL_TIME;
+ if (local->scan_req->chan_time) {
+ /*
+ * Account probe delay to compute the delay needed to reach
+ * chan_time on a given channel.
+ */
+ *next_delay = msecs_to_jiffies(local->scan_req->chan_time);
+ if (*next_delay > IEEE80211_PROBE_DELAY)
+ *next_delay -= IEEE80211_PROBE_DELAY;
+ else
+ *next_delay = 0;
+ } else
+ *next_delay = IEEE80211_CHANNEL_TIME;
local->next_scan_state = SCAN_DECISION;
}
@@ -485,6 +496,7 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
req->n_channels * sizeof(req->channels[0]);
local->hw_scan_req->ie = ies;
local->hw_scan_req->flags = req->flags;
+ local->hw_scan_req->chan_time = req->chan_time;
local->hw_scan_band = 0;
@@ -532,6 +544,9 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
next_delay = IEEE80211_CHANNEL_TIME;
}
+ if (req->chan_time)
+ next_delay = msecs_to_jiffies(req->chan_time);
+
/* Now, just wait a bit and we are all done! */
ieee80211_queue_delayed_work(&local->hw, &local->scan_work,
next_delay);
@@ -696,7 +711,10 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
*/
if (chan->flags & IEEE80211_CHAN_PASSIVE_SCAN ||
!local->scan_req->n_ssids) {
- *next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
+ if (local->scan_req->chan_time)
+ *next_delay = msecs_to_jiffies(local->scan_req->chan_time);
+ else
+ *next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
local->next_scan_state = SCAN_DECISION;
return;
}
--
1.7.9.5
^ permalink raw reply related
* [RFC 3/3] ath10k: respect chan_time parameter in scan request
From: Michal Kazior @ 2013-07-29 8:39 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, ath10k, Michal Kazior
In-Reply-To: <1375087158-22077-1-git-send-email-michal.kazior@tieto.com>
Respect the new scan request parameter.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index da5c333..cd20a20 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2150,6 +2150,12 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw,
arg.vdev_id = arvif->vdev_id;
arg.scan_id = ATH10K_SCAN_ID;
+ if (req->chan_time) {
+ arg.dwell_time_active = req->chan_time;
+ arg.dwell_time_passive = req->chan_time;
+ arg.max_scan_time = 2 * req->chan_time * req->n_channels;
+ }
+
if (!req->no_cck)
arg.scan_ctrl_flags |= WMI_SCAN_ADD_CCK_RATES;
--
1.7.9.5
^ permalink raw reply related
* [RFC] iw: add chan_time scan parameter
From: Michal Kazior @ 2013-07-29 8:42 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Michal Kazior
The new parameter allows user to specify how long
driver should remain on each channel while
scanning.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
Note: nl/cfg/mac patches were sent separately.
Should this be split into two patches - one
that updates nl80211.h and the other adding
the parameter support?
nl80211.h | 8 ++++++++
scan.c | 16 +++++++++++++---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/nl80211.h b/nl80211.h
index 5abc54d..f9ef050 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -1469,6 +1469,12 @@ enum nl80211_commands {
*
* @NL80211_ATTR_COALESCE_RULE: Coalesce rule information.
*
+ * @NL80211_ATTR_SCAN_CHAN_TIME: Specifies how many msec should a driver spend
+ * on each channel during scanning. This is optional and the default is
+ * leave the decision up to the driver. This setting may, but preferrably
+ * shouldn't, be ignored by a driver.
+ *
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1771,6 +1777,8 @@ enum nl80211_attrs {
NL80211_ATTR_COALESCE_RULE,
+ NL80211_ATTR_SCAN_CHAN_TIME,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/scan.c b/scan.c
index 4fb0f23..c5bafd8 100644
--- a/scan.c
+++ b/scan.c
@@ -87,12 +87,13 @@ static int handle_scan(struct nl80211_state *state,
SSID,
MESHID,
DONE,
+ CHANTIME,
} parse = NONE;
int freq;
bool passive = false, have_ssids = false, have_freqs = false;
size_t ies_len = 0, meshid_len = 0;
unsigned char *ies = NULL, *meshid = NULL, *tmpies;
- int flags = 0;
+ int flags = 0, chan_time = 0;
ssids = nlmsg_alloc();
if (!ssids)
@@ -137,6 +138,9 @@ static int handle_scan(struct nl80211_state *state,
} else if (strcmp(argv[i], "meshid") == 0) {
parse = MESHID;
break;
+ } else if (strcmp(argv[i], "chan-time") == 0) {
+ parse = CHANTIME;
+ break;
}
case DONE:
return 1;
@@ -170,6 +174,10 @@ static int handle_scan(struct nl80211_state *state,
meshid_len += 2;
parse = NONE;
break;
+ case CHANTIME:
+ chan_time = strtoul(argv[i], &eptr, 10);
+ parse = NONE;
+ break;
}
}
@@ -198,6 +206,8 @@ static int handle_scan(struct nl80211_state *state,
nla_put_nested(msg, NL80211_ATTR_SCAN_FREQUENCIES, freqs);
if (flags)
NLA_PUT_U32(msg, NL80211_ATTR_SCAN_FLAGS, flags);
+ if (chan_time)
+ NLA_PUT_U32(msg, NL80211_ATTR_SCAN_CHAN_TIME, chan_time);
err = 0;
nla_put_failure:
@@ -1596,7 +1606,7 @@ static int handle_scan_combined(struct nl80211_state *state,
dump_argv[0] = argv[0];
return handle_cmd(state, id, dump_argc, dump_argv);
}
-TOPLEVEL(scan, "[-u] [freq <freq>*] [ies <hex as 00:11:..>] [meshid <meshid>] [lowpri,flush,ap-force] [ssid <ssid>*|passive]", 0, 0,
+TOPLEVEL(scan, "[-u] [freq <freq>*] [ies <hex as 00:11:..>] [meshid <meshid>] [lowpri,flush,ap-force] [chan-time <msec>] [ssid <ssid>*|passive]", 0, 0,
CIB_NETDEV, handle_scan_combined,
"Scan on the given frequencies and probe for the given SSIDs\n"
"(or wildcard if not given) unless passive scanning is requested.\n"
@@ -1606,7 +1616,7 @@ COMMAND(scan, dump, "[-u]",
NL80211_CMD_GET_SCAN, NLM_F_DUMP, CIB_NETDEV, handle_scan_dump,
"Dump the current scan results. If -u is specified, print unknown\n"
"data in scan results.");
-COMMAND(scan, trigger, "[freq <freq>*] [ies <hex as 00:11:..>] [meshid <meshid>] [lowpri,flush,ap-force] [ssid <ssid>*|passive]",
+COMMAND(scan, trigger, "[freq <freq>*] [ies <hex as 00:11:..>] [meshid <meshid>] [lowpri,flush,ap-force] [chan-time <msec>] [ssid <ssid>*|passive]",
NL80211_CMD_TRIGGER_SCAN, 0, CIB_NETDEV, handle_scan,
"Trigger a scan on the given frequencies with probing for the given\n"
"SSIDs (or wildcard if not given) unless passive scanning is requested.");
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox