* Re: iwlwifi connection problems
From: Guy, Wey-Yi @ 2010-07-23 20:38 UTC (permalink / raw)
To: Berg, Johannes, Alex Romosan; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <87tynqvtu6.fsf@sycorax.lbl.gov>
Hi Johannes,
On Fri, 2010-07-23 at 13:14 -0700, Alex Romosan wrote:
> since kernel 2.6.35-rc3 (i didn't try 1 or 2) i haven't been able to
> connect to a hidden wireless access point using the iwlwifi driver. i
> can connect to open ones though (the ones that broadcast their name).
> 2.6.34 worked without any problems. any ideas?
>
> this is with the driver in the standard linux kernel (2.6.35-rc6 is the
> latest one i tried).
Do you aware any changes?
Thanks
Wey
>
^ permalink raw reply
* pull request: wireless-next-2.6 2010-07-23
From: John W. Linville @ 2010-07-23 20:40 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Yet another batch intended for 2.6.36... Mostly the usual random lot
of stuff, mostly driver updates. This batch also includes a flurry
of Sparse-inspired patches from me -- it is hard to resist once the
"bug" bites! As usual, all of these have been cooking in linux-next
for at least several days.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit e955cead031177b083fbf18d04a03c06e330a439:
CAN: Add Flexcan CAN controller driver (2010-07-22 18:06:25 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Bob Copeland (2):
ath5k: move reset to mac80211 workqueue
ath5k: disable tasklets during reset
Bruno Randolf (1):
ath5k: clean up rxlink handling
Christian Lamparter (1):
mac80211: skip HT parsing if HW does not support HT
Dan Carpenter (1):
orinoco_usb: potential null dereference
David Gnedt (1):
mac80211: set carrier on for monitor interfaces on ieee80211_open
Felix Fietkau (3):
ath9k: another fix for the A-MPDU buffer leak
ath9k_hw: remove initvals for hardware which was never sold
mac80211: fix aggregation action frame handling with AP VLANs
Joe Perches (1):
drivers/net/wireless: Remove unnecessary casts of private_data
Johannes Berg (5):
cfg80211: don't get expired BSSes
mac80211: move QoS-enable to BSS info
mac80211: refuse shared key auth when WEP is unavailable
mac80211: fix IBSS lockdep complaint
mac80211: proper IBSS locking
John W. Linville (16):
libertas: convert new uses of __attribute__ ((packed)) to __packed
iwlwifi: convert new uses of __attribute__ ((packed)) to __packed
mac80211: improve error checking if WEP fails to init
wireless: only use alpha2 regulatory information from country IE
wireless: correct sparse warning in lib80211_crypt_tkip.c
wireless: correct sparse warning in wext-compat.c
wireless: correct sparse warning in generated regdb.c
wireless: mark cfg80211_is_all_idle as static
ath9k: correct sparse identified endian bug in ath_paprd_calibrate
ipw2100: mark ipw2100_pm_qos_req static
libipw: correct sparse warnings and mark some variables static
rt2x00: correct sparse warning in rt2x00debug.c
wireless: remove unnecessary reg_same_country_ie_hint
mwl8k: correct/silence sparse warnings
rtl8180: improve signal reporting for rtl8185 hardware
b43: silence most sparse warnings
Kulikov Vasiliy (1):
wireless: airo: delete netdev from list after it is freed
Larry Finger (1):
b43: silence phy_n sparse warnings
Luis R. Rodriguez (2):
ath9k_htc: make ath9k_htc_tx_aggr_oper() static
ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
Maxime Bizon (1):
cfg80211: fix race between sysfs and cfg80211
Pavel Roskin (1):
ath9k: remove unneeded calculation of minimal calibration power
Rajkumar Manoharan (1):
ath9k: fix panic while cleaning up virtaul wifis
Vivek Natarajan (1):
ath9k: Fix the LED behaviour in idle unassociated state.
Wey-Yi Guy (3):
iwlwifi: additional statistic debug counter
iwlwifi: more statistics counter for agn in debugfs
iwlwifi: "recover_from_tx_stall" function for 4965
drivers/net/wireless/airo.c | 24 +-
drivers/net/wireless/ath/ath5k/base.c | 65 +-
drivers/net/wireless/ath/ath5k/base.h | 4 +-
drivers/net/wireless/ath/ath5k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 66 -
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 4141 ++++++----------------
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 31 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 7 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 -
drivers/net/wireless/ath/ath9k/eeprom_def.c | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 18 +-
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 21 +-
drivers/net/wireless/ath/ath9k/xmit.c | 19 +-
drivers/net/wireless/b43/main.c | 2 +-
drivers/net/wireless/b43/phy_g.c | 2 +-
drivers/net/wireless/b43/phy_lp.c | 8 +-
drivers/net/wireless/b43/phy_n.c | 16 +-
drivers/net/wireless/b43/wa.c | 8 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
drivers/net/wireless/ipw2x00/libipw_module.c | 4 +-
drivers/net/wireless/ipw2x00/libipw_wx.c | 4 -
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 7 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 7 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 10 +-
drivers/net/wireless/libertas/cfg.c | 6 +-
drivers/net/wireless/libertas/debugfs.c | 4 +-
drivers/net/wireless/libertas/host.h | 6 +-
drivers/net/wireless/mwl8k.c | 22 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 10 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 2 +-
drivers/net/wireless/rtl818x/rtl8180_dev.c | 11 +-
include/net/cfg80211.h | 4 +
include/net/mac80211.h | 11 +-
include/net/regulatory.h | 1 -
net/mac80211/cfg.c | 4 -
net/mac80211/ht.c | 2 +-
net/mac80211/ibss.c | 92 +-
net/mac80211/ieee80211_i.h | 7 +-
net/mac80211/iface.c | 6 +-
net/mac80211/mlme.c | 13 +-
net/mac80211/util.c | 7 +-
net/mac80211/wep.c | 5 +-
net/wireless/core.c | 14 +-
net/wireless/genregdb.awk | 1 +
net/wireless/lib80211_crypt_tkip.c | 2 +-
net/wireless/reg.c | 654 +----
net/wireless/scan.c | 5 +
net/wireless/sme.c | 2 +-
net/wireless/wext-compat.c | 1 +
52 files changed, 1405 insertions(+), 3987 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-07-23.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* new stuff for 2.6.36 needs to be posted _now_
From: John W. Linville @ 2010-07-23 20:45 UTC (permalink / raw)
To: linux-wireless
You may have noticed that when Linus released 2.6.35-rc6, he
optimistically predicted that it will be the last -rc for 2.6.35.
So, the merge window is around the corner!
For those that need a reminder, the opening of the merge window is a
_deadline_ for new features. Once the merge window opens, only fixes
will be accepted for 2.6.36. In fact, any non-fix patches need to
already be in wireless-next-2.6 when the merge window opens if you want
them in 2.6.36. That means you need to get them posted _now_, so they
can be reviewed and I can find time to merge them before the deadline.
You have been warned...this means you!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-23
From: David Miller @ 2010-07-23 21:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100723204029.GD2426@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 23 Jul 2010 16:40:29 -0400
> Yet another batch intended for 2.6.36... Mostly the usual random lot
> of stuff, mostly driver updates. This batch also includes a flurry
> of Sparse-inspired patches from me -- it is hard to resist once the
> "bug" bites! As usual, all of these have been cooking in linux-next
> for at least several days.
>
> Please let me know if there are problems!
Auto-merging drivers/net/wireless/iwlwifi/iwl-commands.h
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-commands.h
I don't even have to look at the file to know that it's
another one of those __packed things.
I'll fix it up again, but I know you can sense how tiring
this has become for me.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-23
From: John W. Linville @ 2010-07-23 21:39 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
In-Reply-To: <20100723.140320.116366019.davem@davemloft.net>
On Fri, Jul 23, 2010 at 02:03:20PM -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Fri, 23 Jul 2010 16:40:29 -0400
>
> > Yet another batch intended for 2.6.36... Mostly the usual random lot
> > of stuff, mostly driver updates. This batch also includes a flurry
> > of Sparse-inspired patches from me -- it is hard to resist once the
> > "bug" bites! As usual, all of these have been cooking in linux-next
> > for at least several days.
> >
> > Please let me know if there are problems!
>
> Auto-merging drivers/net/wireless/iwlwifi/iwl-commands.h
> CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-commands.h
>
> I don't even have to look at the file to know that it's
> another one of those __packed things.
>
> I'll fix it up again, but I know you can sense how tiring
> this has become for me.
I'm sorry, Dave! I should have done a for-davem branch. FWIW,
I intended to do a test merge but it must have slipped my fragile
mind. :-(
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: drago01 @ 2010-07-23 22:32 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <1279823849.32290.1.camel@wwguy-ubuntu>
On Thu, Jul 22, 2010 at 8:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> Hi drago,
>
>
> On Wed, 2010-07-21 at 14:00 -0700, drago01 wrote:
>> On Wed, Jul 21, 2010 at 10:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> > Hi drago,
>> > On Wed, 2010-07-21 at 12:59 -0700, drago01 wrote:
>> >> On Tue, Jul 20, 2010 at 1:56 AM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> >> > Hi drago,
>> >> >
>> >> >
>> >> > Are you using 5350? here I attach a "RFC patch", could you give a try to
>> >> > see if it help?
>> >>
>> >> Not quite I am on 5300; your patch seem to only touch the 5350 code
>> >> ... should I try the same change for 5300?
>> >
>> > Yes, please
>>
>> Hi,
>>
>> As there is no such field in .34 I patched the .35 driver which seems
>> to be fine with the change ... I couldn't trigger it using the close
>> lid (no suspend) and wait a bit trick ... but I have not used it for
>> long enough to say for certain that its gone.
>>
>> But unfortunately the driver has a different issue it spams my log with tons of:
>>
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>>
> Yes, I aware of this, this is introduced by a recent patch
> commit d9763a384216336e180399b69461eae37f6c4f54
>
> I will work on a new patch to help address this.
OK, as for the other patch after a day in use I could not trigger the
problem so it does indeed fix it.
Thanks
^ permalink raw reply
* Re: [PATCH] zd1211rw: make CR_INTERRUPT cast explicit
From: Pavel Roskin @ 2010-07-23 22:55 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <20100722190339.GD2616@tuxdriver.com>
On Thu, 2010-07-22 at 15:03 -0400, John W. Linville wrote:
> On Wed, Jul 21, 2010 at 12:36:58PM -0400, Pavel Roskin wrote:
> > I think __force should be used sparingly, especially outside headers. I
> > tried other ways to prevent the warning. I tried declaring int_num as
> > zd_addr_t, but sparse keeps complaining about the same comparison.
>
> Actually, it looks like it works w/o the "__force" as well.
> Any objection to a version like that?
Ideally, I would avoid any workarounds for sparse. The bug was
acknowledged by a sparse developer, so I expect it to be fixed.
http://www.spinics.net/lists/linux-sparse/msg02167.html
However, a version without __force would be more acceptable than a
version with __force.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: wl1271 firmware
From: Pazzo Da Legare @ 2010-07-23 23:19 UTC (permalink / raw)
To: Luciano Coelho
Cc: linux-wireless@vger.kernel.org, Levi, Shahar, Logan Gunthorpe
In-Reply-To: <1279816465.1630.9.camel@powerslave>
Dear Luciano,
Obviously you are right: I did a stupid error (I modified wrong
wl1271.h file, the one for and older compact-wireless...), sorry for
that.
I attached what I got. Note that I have a limited buffer for system
log so this is the last part only, I hope is enough.
http://pastebin.com/7nLJeXkb
Thank you again,
pz
2010/7/22 Luciano Coelho <luciano.coelho@nokia.com>:
> On Thu, 2010-07-22 at 17:41 +0200, ext Pazzo Da Legare wrote:
>> I enabled the DEBUG_LEVEL as you advice me but I have no additional
>> information....
>>
>> [ 186.230000] wl1271_sdio mmc0:0001:2: firmware: requesting
>> wl1271-fw.bin
>> [ 186.420000] wl1271_sdio mmc0:0001:2: firmware: requesting
>> wl1271-nvs.bin
>> [ 186.860000] wl1271: firmware booted (Rev 6.1.0.0.310)
>> [ 186.880000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 187.380000] wl1271: ERROR ELP wakeup timeout!
>> [ 187.880000] wl1271: ERROR ELP wakeup timeout!
>
> There's something wrong. There should have been a lot more traces with
> the DEBUG_LEVEL I proposed. Please try again.
>
>
> --
> Cheers,
> Luca.
>
>
^ permalink raw reply
* Re: Wireless card on Debian squeeze
From: Pavel Roskin @ 2010-07-23 23:27 UTC (permalink / raw)
To: Nicholas Syrotiuk; +Cc: linux-wireless
In-Reply-To: <4C488BD9.8040809@manchester.ac.uk>
On Thu, 2010-07-22 at 19:20 +0100, Nicholas Syrotiuk wrote:
> Dear Linux Wireless users,
>
> I'm having some trouble installing the correct driver on my laptop. I'm
> slightly confused about the revision numbering of my wireless hardware;
> that is, I'm not sure if it's revision 2 or 3.
>
> My kernel is: 2.6.32-5
> Relevant output from lspci is:
> 02:03.0 Network controller [0280]: Broadcom Corporation BCM4306
> 802.11b/g Wireless LAN Controller [14e4:4320] (rev 02)
> Subsystem: Dell TrueMobile 1300 WLAN Mini-PCI Card [1028:0001]
> Flags: bus master, fast devsel, latency 32, IRQ 5
> Memory at fafee000 (32-bit, non-prefetchable) [size=8K]
> Kernel driver in use: b43-pci-bridge
> -----------------------------------------------
>
> It looks like I need the b43legacy driver, which comes in a separate
> Debian package called "firmware-b43legacy-installer." When I install
> this package, computer says: "Not supported card. Use b43 firmware."
>
> When I install b43 firmware, configure the interface and bring it up,
> computer says: "Firmware file b43legacy/ucode4.fw not found or load failed."
I believe the drivers should be trusted since there they access the
actual hardware. The above message is from b43legacy. It must have
found the card, so the card needs b43legacy.
That means that firmware-b43legacy-installer is wrong. I don't have
Debian handy, but I checked its source, and it should work for your
card.
That's the page:
http://packages.debian.org/sid/firmware-b43legacy-installer
And that's the source:
http://ftp.de.debian.org/debian/pool/contrib/b/b43-fwcutter/b43-fwcutter_013-2.debian.tar.gz
I ran your "lspci -n" output through the
firmware-b43legacy-installer.postinst script and it doesn't complain.
> So, I am slightly confounded. However, it has occurred to me that I may
> be getting the packages from the wrong source, which are currently:
>
> deb http://debian.man.ac.uk/debian squeeze main
> deb http://ftp.us.debian.org/debian squeeze main contrib
Make sure your apt-get knows about the latest packages, that is run
"apt-get update". Then try installing firmware-b43legacy-installer.
If it doesn't work, download the package from the above page and install
it with dpkg. Alternatively, you could generate the firmware manually,
as described at http://linuxwireless.org/en/users/Drivers/b43
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: ath9k - D-link DWA-552
From: Pavel Roskin @ 2010-07-24 2:02 UTC (permalink / raw)
To: Andy Pyles; +Cc: linux-wireless
In-Reply-To: <AANLkTil3u8uFbH7WyPuvqu0wee4KsojqPUsAH2kupZhJ@mail.gmail.com>
On Wed, 2010-07-21 at 14:58 -0400, Andy Pyles wrote:
> I have recently purchased two of these cards. ( the markings on the
> outside indicate they have are same hardware revision). I am noticing
> some strange behavior on one of them:
...
> $lspci -n output:
> 05:05.0 0200: 168c:ff1d (rev 01)
This looks like some experimental version that was not meant to be sold.
> Has anyone else seen this behavior with Card Two? I tried swapping to
> a different PCI slot, even to a different PC.
> Same symptom. I also tried modifying pci.c in ath9k driver to no effect.
If you add the PCI ID to the driver, something should change. The
driver would try to initialize the card. If it fails, you should get
some message in the kernel log, which can be seen by running dmesg.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: new stuff for 2.6.36 needs to be posted _now_
From: Marcel Holtmann @ 2010-07-24 2:23 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100723204529.GE2426@tuxdriver.com>
Hi John,
> You may have noticed that when Linus released 2.6.35-rc6, he
> optimistically predicted that it will be the last -rc for 2.6.35.
> So, the merge window is around the corner!
>
> For those that need a reminder, the opening of the merge window is a
> _deadline_ for new features. Once the merge window opens, only fixes
> will be accepted for 2.6.36. In fact, any non-fix patches need to
> already be in wireless-next-2.6 when the merge window opens if you want
> them in 2.6.36. That means you need to get them posted _now_, so they
> can be reviewed and I can find time to merge them before the deadline.
you did see my pull request for bluetooth-next-2.6 tree? I have two
additional patches that should go in, but I wait until you pulled that
one first.
Regards
Marcel
^ permalink raw reply
* Re: ath9k - D-link DWA-552
From: Andy Pyles @ 2010-07-24 2:30 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <1279936945.27462.2.camel@mj>
Hi Pavel,
Incidentally this is the output after adding that id to pci.c:
[ 1211.423855] Backport based on linux-next.git next-20100720
[ 1211.437076] cfg80211: World regulatory domain updated:
[ 1211.437080] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 1211.437084] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1211.437087] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1211.437089] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 1211.437092] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1211.437095] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 1211.447705] ath9k 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 1211.447794] ath9k 0000:05:02.0: Failed to initialize device
[ 1211.447830] ath9k 0000:05:02.0: PCI INT A disabled
[ 1211.447859] ath9k: probe of 0000:05:02.0 failed with error -95
On Fri, Jul 23, 2010 at 10:02 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Wed, 2010-07-21 at 14:58 -0400, Andy Pyles wrote:
>> I have recently purchased two of these cards. ( the markings on the
>> outside indicate they have are same hardware revision). I am noticing
>> some strange behavior on one of them:
> ...
>> $lspci -n output:
>> 05:05.0 0200: 168c:ff1d (rev 01)
>
> This looks like some experimental version that was not meant to be sold.
>
>> Has anyone else seen this behavior with Card Two? I tried swapping to
>> a different PCI slot, even to a different PC.
>> Same symptom. I also tried modifying pci.c in ath9k driver to no effect.
>
> If you add the PCI ID to the driver, something should change. The
> driver would try to initialize the card. If it fails, you should get
> some message in the kernel log, which can be seen by running dmesg.
>
> --
> Regards,
> Pavel Roskin
>
^ permalink raw reply
* RE: iwlagn and many firmware restarts with Fedora kernel
From: Guy, Wey-Yi W @ 2010-07-24 4:34 UTC (permalink / raw)
To: drago01; +Cc: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTi=qKLVEKKKopWdnxS41ny5S6zV6RSCptSE+a8Sf@mail.gmail.com>
Hi drago,
-----Original Message-----
From: drago01 [mailto:drago01@gmail.com]
Sent: Friday, July 23, 2010 3:32 PM
To: Guy, Wey-Yi W
Cc: Marcel Holtmann; linux-wireless@vger.kernel.org
Subject: Re: iwlagn and many firmware restarts with Fedora kernel
On Thu, Jul 22, 2010 at 8:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> Hi drago,
>
>
> On Wed, 2010-07-21 at 14:00 -0700, drago01 wrote:
>> On Wed, Jul 21, 2010 at 10:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> > Hi drago,
>> > On Wed, 2010-07-21 at 12:59 -0700, drago01 wrote:
>> >> On Tue, Jul 20, 2010 at 1:56 AM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> >> > Hi drago,
>> >> >
>> >> >
>> >> > Are you using 5350? here I attach a "RFC patch", could you give a try to
>> >> > see if it help?
>> >>
>> >> Not quite I am on 5300; your patch seem to only touch the 5350 code
>> >> ... should I try the same change for 5300?
>> >
>> > Yes, please
>>
>> Hi,
>>
>> As there is no such field in .34 I patched the .35 driver which seems
>> to be fine with the change ... I couldn't trigger it using the close
>> lid (no suspend) and wait a bit trick ... but I have not used it for
>> long enough to say for certain that its gone.
>>
>> But unfortunately the driver has a different issue it spams my log with tons of:
>>
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>>
> Yes, I aware of this, this is introduced by a recent patch
> commit d9763a384216336e180399b69461eae37f6c4f54
>
> I will work on a new patch to help address this.
OK, as for the other patch after a day in use I could not trigger the
problem so it does indeed fix it.
Great, thank you very much for testing it. I will prepare the patch for upstream.
Btw, I also have patch to help the other problem you encounter.
Wey
^ permalink raw reply
* Re: [PATCH] mac80211: simplify key locking
From: Jouni Malinen @ 2010-07-24 5:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1275380359.3621.17.camel@jlt3.sipsolutions.net>
On Tue, Jun 01, 2010 at 10:19:19AM +0200, Johannes Berg wrote:
> net/mac80211/key.c
commit ad0e2b5a00dbec303e4682b403bb6703d11dcdb2
> void ieee80211_key_free(struct ieee80211_key *key)
> - if (!key->sdata) {
> - /* The key has not been linked yet, simply free it
> - * and don't Oops */
It looks like this function can still be called with key->sdata == NULL
in some cases and that does indeed result in an oops below:
> + local = key->sdata->local;
I've seen this issue pop up in FT testing and based on a quick code
review, at least ieee80211_add_key() calls ieee80211_key_free() in an
error case (sta not found) without having first called
ieee80211_key_link(). Which one is wrong - the caller or the freeing
function? Should we just restore the previous key->sdata == NULL handler
here?
I'd guess that the sta-not-found part is caused by FT trying to
configure PTK before association in the FT protocol roaming case
(wpa_supplicant tries to do this as soon as it knows the key because
that works with some drivers and is needed to avoid race condition with
encrypted frames; as a workaround, it will do this again after
association if the previous attempt failed).
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: ath9k - D-link DWA-552
From: Pavel Roskin @ 2010-07-24 6:28 UTC (permalink / raw)
To: Andy Pyles; +Cc: linux-wireless
In-Reply-To: <AANLkTimnFGidxLvnR+=WXykQyf4NNAJBkxuqZ3HWRdeh@mail.gmail.com>
On Fri, 2010-07-23 at 22:30 -0400, Andy Pyles wrote:
> Hi Pavel,
>
> Incidentally this is the output after adding that id to pci.c:
>
> [ 1211.423855] Backport based on linux-next.git next-20100720
> [ 1211.437076] cfg80211: World regulatory domain updated:
> [ 1211.437080] (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ 1211.437084] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 1211.437087] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 1211.437089] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 1211.437092] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 1211.437095] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 1211.447705] ath9k 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> [ 1211.447794] ath9k 0000:05:02.0: Failed to initialize device
> [ 1211.447830] ath9k 0000:05:02.0: PCI INT A disabled
> [ 1211.447859] ath9k: probe of 0000:05:02.0 failed with error -95
You may want to post it to ath9k-devel@lists.ath9k.org
It looks like a hardware problem. Either the device is broken, or it's
an experimental chip that is not supported by ath9k. There have been
patches removing support for cards that have never been sold (or were
not supposed to be sold). Maybe your card ended up with an experimental
chip by mistake.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] mac80211: Don't set per-BSS QoS for monitor interfaces
From: Johannes Berg @ 2010-07-24 7:35 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Sujith, linville, linux-wireless
In-Reply-To: <AANLkTim0Zv8E6Kc60W9m6krL-FOzXiJpeHTGgoR2DH9i@mail.gmail.com>
On Fri, 2010-07-23 at 10:29 -0700, Luis R. Rodriguez wrote:
> On Thu, Jul 22, 2010 at 11:01 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Fri, 2010-07-23 at 10:47 +0530, Sujith wrote:
> >> In AP mode, there is no need to notify the driver about QoS
> >> changes for the monitor interface that is created. The warning
> >> in ieee80211_bss_info_change_notify() would be hit otherwise.
> >
> > Makes sense.
> >
> > Acked-by: Johannes Berg <johannes@sipsolutions.net>
> >> Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
>
> Stable?
Err, no, the change that does this isn't going in until .36 I think.
johannes
^ permalink raw reply
* Re: Atheros 0cf3:b003
From: sergi @ 2010-07-24 8:04 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTimpwMyfcvRGnJ1JfZP+F=4nFNT5Ra3pB3vse1LM@mail.gmail.com>
Luis R. Rodriguez <mcgrof@...> writes:
>
> 2010/7/23 Maximi89 <maximi89@...>:
> > Hola Luis, conoces ese ID?, Atheros 0cf3:b003
> > Es efectivamente un AR9271?
>
> No, cual tarjeta es esa? Las que tenemos son estos:
>
> { },
> };
>
> Stephen, have you heard of 0cf3:b003 as an ar9271 or HB94 card?
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Hola Luis yo fui quien le mando la consulta a maximiliano,,mi lapiz usb es de
la casa Ubiquiti modelo wifistation ext y ahi dicen k tiene el atheros 9271..y
el id k me sale es el mencionado,,tanto en Mac,Linux y con Everest en win,uso
Ubuntu Ultimate 2.7 con kernel 2.6.32-24 y nada k no me funciona,Podria cmbiar
el Id para k sea compatible?? ..bueno muchas gracias por tu atencion
^ permalink raw reply
* Re: [PATCH] mac80211: simplify key locking
From: Johannes Berg @ 2010-07-24 9:06 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John Linville, linux-wireless
In-Reply-To: <20100724053301.GA6773@jm.kir.nu>
On Fri, 2010-07-23 at 22:33 -0700, Jouni Malinen wrote:
> On Tue, Jun 01, 2010 at 10:19:19AM +0200, Johannes Berg wrote:
>
> > net/mac80211/key.c
> commit ad0e2b5a00dbec303e4682b403bb6703d11dcdb2
>
> > void ieee80211_key_free(struct ieee80211_key *key)
>
> > - if (!key->sdata) {
> > - /* The key has not been linked yet, simply free it
> > - * and don't Oops */
>
> It looks like this function can still be called with key->sdata == NULL
> in some cases and that does indeed result in an oops below:
>
> > + local = key->sdata->local;
>
>
> I've seen this issue pop up in FT testing and based on a quick code
> review, at least ieee80211_add_key() calls ieee80211_key_free() in an
> error case (sta not found) without having first called
> ieee80211_key_link(). Which one is wrong - the caller or the freeing
> function? Should we just restore the previous key->sdata == NULL handler
> here?
I think it's just another stupid bug.
I removed the comment because the linked vs. not linked handling is a
bit different now I think ... I don't think we should restore the NULL
handling as it was before, since __ieee80211_key_free() should be able
to handle this now.
The fix should be passing in the local pointer to ieee80211_key_free() I
guess. Can you try that?
johannes
^ permalink raw reply
* [PATCH] rt2x00: Fix regression for rt2500pci
From: Ivo van Doorn @ 2010-07-24 17:32 UTC (permalink / raw)
To: John W. Linville; +Cc: users, linux-wireless
Since commit:
commit f1aa4c541e98afa8b770a75ccaa8504d0bff44a7
Author: Ivo van Doorn <ivdoorn@gmail.com>
Date: Tue Jun 29 21:38:55 2010 +0200
rt2x00: Write the BSSID to register when interface is added
mananged mode in rt2500pci was broken, due to intf->bssid containing
random data rather then the expected 00:00:00:00:00:00
This is corrected by sending the BSSID to rt2x00lib_config_intf
only in AP mode where the bssid is set to a valid value.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2x00mac.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index 4d8d232..235e037 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -273,17 +273,24 @@ int rt2x00mac_add_interface(struct ieee80211_hw *hw,
mutex_init(&intf->beacon_skb_mutex);
intf->beacon = entry;
- if (vif->type == NL80211_IFTYPE_AP)
- memcpy(&intf->bssid, vif->addr, ETH_ALEN);
- memcpy(&intf->mac, vif->addr, ETH_ALEN);
-
/*
* The MAC adddress must be configured after the device
* has been initialized. Otherwise the device can reset
* the MAC registers.
+ * The BSSID address must only be configured in AP mode,
+ * however we should not send an empty BSSID address for
+ * STA interfaces at this time, since this can cause
+ * invalid behavior in the device.
*/
- rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
- intf->mac, intf->bssid);
+ memcpy(&intf->mac, vif->addr, ETH_ALEN);
+ if (vif->type == NL80211_IFTYPE_AP) {
+ memcpy(&intf->bssid, vif->addr, ETH_ALEN);
+ rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
+ intf->mac, intf->bssid);
+ } else {
+ rt2x00lib_config_intf(rt2x00dev, intf, vif->type,
+ intf->mac, NULL);
+ }
/*
* Some filters depend on the current working mode. We can force
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: orphan the atmel wireless driver
From: Simon Kelley @ 2010-07-24 18:59 UTC (permalink / raw)
To: John W. Linville; +Cc: Dan Williams, linux-wireless
In-Reply-To: <20100723132847.GC6678@tuxdriver.com>
John W. Linville wrote:
> On Fri, Jul 23, 2010 at 10:07:35AM +0100, Simon Kelley wrote:
>> Dan Williams wrote:
>>> On Thu, 2010-07-22 at 14:31 -0400, John W. Linville wrote:
>>>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>> Aww, how sad :(. I'll take it since I still have some of this
>>> hardware. Not that I'll do much with it, but if the patches are simple
>>> I'm happy to test+ack them.
>>>
>> Thanks Dan, whilst I still have the hardware, I no longer have a
>> convenient PCMCIA slot into which to plug it.
>>
>> This hardware is well orphaned: it never made is past 802.11b, and there
>> have been no new models for a long time. Nevertheless, if the existing
>> code can be kept functional, that would be good.
>
> Is the existing code functional? The device I have seems to only
> half work -- I suppose I need to figure that out...
>
> John
I'm not aware of any problems. I'll try and test a new kernel when I can
find a PCMCIA-full laptop. If the problem turns out to be your hardware,
John, I can send you another card.
Cheers,
Simon.
^ permalink raw reply
* Compat-wireless release for 2010-07-24 is baked
From: Compat-wireless cronjob account @ 2010-07-24 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
493730 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5764 - backport from compat module
7211 - total backport code
1.4605 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2467 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100723
compat-wireless release: compat-wireless-2010-07-13-4-g04898a5
^ permalink raw reply
* Re: Master mode in rtl8187
From: Hin-Tak Leung @ 2010-07-24 21:26 UTC (permalink / raw)
To: Larry Finger; +Cc: Ben Gamari, linux-wireless
In-Reply-To: <4C474851.4000809@lwfinger.net>
On 7/21/10, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 07/21/2010 01:17 PM, Ben Gamari wrote:
>> Hey all,
>>
>> I recently purchased a Netgear WG111v2 (based on rtl8187b) and after
>> seeing scattered reports[1] that master mode may be supported by the
>> rtl8187 driver. Unfortunately, hostapd throws up when it attempts to put
>> the card into master mode. Is master mode supported by this driver? I've
>> tried both 2.6.34 as well as the latest wireless-testing tree and
>> neither seem to work.
>
> My WG111V2 has an RTL8187L chip in it, not an RTL8187B. No, master mode is
> NOT
> supported by this driver. Adding that feature has been on my list of things
> to
> do, but the priority is very low. I really have little desire to convert my
> $600
> laptop into a $40 access point.
>
>> I noticed there was a patch[2] sent out a few years back, but it seems
>> no one followed up. While I don't have much experience working with
>> wireless hardware I've done kernel driver work before, so with some
>> guidance I might be able to finish up that patch. Any input would be
>> greatly appreciated. Thanks!
>
>> [1]
>> http://osdir.com/ml/linux.kernel.wireless.general/2007-07/msg00289.html
>> [2]
>> http://osdir.com/ml/linux.kernel.wireless.general/2007-06/msg00455.html
>
> That patch is useless. The rtl8187 driver and mac80211 have changed so much
> that
> it cannot be made to apply, and would not be likely to work.
>
> One other thing to consider. The RTL8187L has only a single transmit queue.
> Will
> the device be able to transmit beacons with an appropriate timing accuracy?
>
> To modify the driver, you will need to study some other driver that does
> work in
> master mode.
There were some discussion a while back that some generic master mode
support for all mac80211-based drivers might eventually happen. Is
that still the case?
Hin-Tak
^ permalink raw reply
* Re: [PATCH v2 10/20] omap: zoom: add fixed regulator device for wlan
From: Ohad Ben-Cohen @ 2010-07-25 10:40 UTC (permalink / raw)
To: Mark Brown
Cc: Roger Quadros, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org, Kalle Valo,
Pandita Vikram, linux@arm.linux.org.uk, Nicolas Pitre,
Tony Lindgren, San Mehat, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20100723091503.GA12300@rakim.wolfsonmicro.main>
On Fri, Jul 23, 2010 at 12:15 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Jul 23, 2010 at 02:13:38AM +0300, Ohad Ben-Cohen wrote:
>> On Thu, Jul 22, 2010 at 2:16 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
>> > .dev_name = "mmci-omap-hs.2"
>
>> I already set the .dev member of the consumer in a similar manner to
>> how all other regulators are configured in this board - please check
>> out patch 13:
>
>> https://patchwork.kernel.org/patch/113418/
>
>> Does this look reasonable to you ?
>
> You should really be using dev_name in preference to dev these days
> unless there's a *very* good reason.
Changed, thank you.
I'll submit the updated patch now as a standalone patch as it has no
dependencies on the whole series, and it could only help to start
trimming that series down.
>
^ permalink raw reply
* [PATCH] omap: zoom: add fixed regulator device for wl1271
From: Ohad Ben-Cohen @ 2010-07-25 11:14 UTC (permalink / raw)
To: linux-omap
Cc: linux-wireless, linux-mmc, Mark Brown, linux-arm-kernel,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
San Mehat, Roger Quadros, Tony Lindgren, Nicolas Pitre,
Pandita Vikram, Kalle Valo, Ohad Ben-Cohen
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
This patch is a follow-up to a previous wl1271 discussion,
thus all original recipients are CC'ed.
arch/arm/mach-omap2/board-zoom-peripherals.c | 35 ++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..de88635 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,6 +16,7 @@
#include <linux/gpio.h>
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -27,6 +28,8 @@
#include "mux.h"
#include "hsmmc.h"
+#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
+
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -106,6 +109,11 @@ static struct regulator_consumer_supply zoom_vmmc2_supply = {
.supply = "vmmc",
};
+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ .supply = "vmmc",
+ .dev_name = "mmci-omap-hs.2",
+};
+
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -151,6 +159,32 @@ static struct regulator_init_data zoom_vsim = {
.consumer_supplies = &zoom_vsim_supply,
};
+static struct regulator_init_data zoom_vmmc3 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &zoom_vmmc3_supply,
+};
+
+static struct fixed_voltage_config zoom_vwlan = {
+ .supply_name = "vwl1271",
+ .microvolts = 1800000, /* 1.8V */
+ .gpio = OMAP_ZOOM_WLAN_PMENA_GPIO,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = &zoom_vmmc3,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &zoom_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] __initdata = {
{
.name = "external",
@@ -280,6 +314,7 @@ static void enable_board_wakeup_source(void)
void __init zoom_peripherals_init(void)
{
omap_i2c_init();
+ platform_device_register(&omap_vwlan_device);
usb_musb_init(&musb_board_data);
enable_board_wakeup_source();
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2 18/20] mmc: sdio: enable a default power off mode of the card
From: Ohad Ben-Cohen @ 2010-07-25 12:40 UTC (permalink / raw)
To: Roger Quadros
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Tony Lindgren, Nicolas Pitre, Pandita Vikram,
Kalle Valo
In-Reply-To: <4C482D01.1040109@nokia.com>
On Thu, Jul 22, 2010 at 2:35 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
> On 07/21/2010 08:33 PM, ext Ohad Ben-Cohen wrote:
>>
>> Add support for an SDIO device to stay powered off even without
>> the presence of an SDIO function driver. A host should explicitly
>> ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO
>> function driver should know it needs to call sdio_claim_power
>> before accessing the device.
>>
>> Signed-off-by: Ohad Ben-Cohen<ohad@wizery.com>
>
> Shouldn't this be the default behaviour? If there is no function driver for
> any of the functions of the card, then sdio core shold power off the card.
>
> I don't see a need for a special capability flag for this.
>
> in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability
Totally agree.
I didn't want to change the current behavior of the cards/funcs so I
looked for a way to explicitly power down only specific cards.
Alternatively we could power down all cards at the end
mmc_attach_sdio, and then power them up selectively in sdio_bus_probe,
just before calling probe. If the probe succeeds, the function driver
takes over. If the probe fails, we can power them down again.
Is that what you meant ?
This would work both if the sdio function driver is already loaded, or
will only be loaded at a later time. But I'm not too fond of the extra
power on/off cycles that it will introduce for each card..
Thanks,
Ohad.
> flag, it seems more like a request from the board to keep the card powered
> off.
>
> regards,
> -roger
>
^ 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