Re:

Re:

[Michael Buesch]

On Wednesday 14 March 2007 16:32, Larry Finger wrote:
> During testing of bcm43xx interference mitigation, two problems were
> discovered:
> 
> (1) When the MANUALWLAN mode was set, routines _stack_save and _stack_restore
>     generated assertions that were traced to saving ILT registers with addresses
>     > 0xFFF. This problem was fixed by adding one bit to the field used for
>     the offset, and subtracting one bit from the space used for the id.
> (2) In MANUALWLAN mode, the IRQ XMIT errors are generated. The cause of these
>     errors has not yet been located. Any suggestions on debugging this problem
>     would be greatly appreciated.

Interference mitigation code is broken and has always been. It never worked.
So no wonder it doesn't work now. ;)
I'd suggest to first fix that (by a rewrite) before you do any code
that's based on it (like this ACI stuff).

I won't do it. interf mitigation is an uninterresting feature to me.

-- 
Greetings Michael.

Re:

[Stefano Brivio]

On Sun, 23 Dec 2007 13:19:51 +0100
"Mattias Nissler" <Mattias.Nissler@gmx.de> wrote:

> Hey,
> 
> I'm a little late on this and away from my development machine anyway, but
> when reading my email, I noticed the following and thought this is
> important enough to point out, even though I only have that crappy
> webmailer and the only kernel tree I can look at is wireless-2.6/everything
> on git.kernel.org
> 
> In rc80211_pid.h, you have the following (this from the wireless-2.6 tree):
> 
>         /* Sampling period for measuring percentage of failed frames. */
>         #define RC_PID_INTERVAL (HZ / 8)
> 
> But rc80211_pid_algo.c says:
> 
>         period = (HZ * pinfo->sampling_period + 500) / 1000;
>         if (!period)
>                 period = 1;
> 
> You see this is completely bogus. My original patch had:
> 
>         /* Sampling period for measuring percentage of failed frames in 0.001s. */
>         #define RC_PID_INTERVAL 1000
> 
> You see why what you posted and John commited is bogus?

Indeed. I didn't notice about this because HZ == 1000 on my laptop. But I
didn't even sign off that patch, I just added a From: on top of it,
and changed this:

+#define RC_PID_INTERVAL (HZ / 1)
[yes, this is present in your original - as sent through IRC - patch]

to:

+#define RC_PID_INTERVAL (HZ / 8)
[and IIRC we discussed about this on IRC]

I'll post a fix for this.

> I'm getting a little fed up with this, you keep screwing up the code with
> my name on it *sigh*

Please, could you show _exactly_ which patches with your name (as in,
From: you) you think I screwed up?

I don't think I screwed up anything yours. I would be very sorry otherwise.

> And again, I still don't think guarding against period == 0 is the right
> thing to do. As I explained privately in IRC, we should make sure the
> sample_interval is larger than HZ when setting the sample_interval
> variable  (once nl80211 is done). It doesn't make sense to do this check
> every time we execute the code when we can do it once in advance.

Exactly, once nl80211 is done. Now, what if the control interval gets
changed after initialization? How often should we check whether it's larger
than HZ? If you got another solution which would work together with the
current debugfs interface, please post it.

> Sigh.

Please stop this. I think that this is:
1) not correct (but I don't care that much);
2) useless;
3) confusing.

Sorry again if I actually screwed up anything.


--
Ciao
Stefano

Re:

[Pavel Roskin]

Quoting Adam Turk <bofh1234@hotmail.com>:

>
> Hello,
>
> I just compiled 2.6.25-rc6 and got a bunch of warnings when I did   
> make modules_install. I am using a PC not a laptop so I don't bother  
>  compiling PCMCIA support.
>
> WARNING:   
> /lib/modules/2.6.25-rc6/updates/drivers/net/usb/rndis_host.ko needs   
> unknown symbol usbnet_skb_return

Just remove /lib/modules/2.6.25-rc6 and reinstall the modules.  It's  
probably modules installed by compat-wireless that were compiled for a  
kernel with the same version but different settings.

-- 
Regards,
Pavel Roskin

Re:

[Bruno Randolf]

On Monday 14 July 2008 18:18:02 Bruno Randolf wrote:
> unsubscribe

erm, sorry for that embarassing mistake...
i'm going to follow the list thru gmane news from now on.

bruno

Re:

[Stefanik Gábor]

On Sun, Aug 3, 2008 at 12:33 PM, Angel Mieres <mieres.angel@gmail.com> wrote:
> unsubscribe linux-wireless

Send it to majordomo@vger.kernel.org, not here.

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re:

[Luis R. Rodriguez]

On Sat, Sep 13, 2008 at 9:10 AM, Edgar Velasco <ingeideas@yahoo.com> wrote:
> I'm reporting a bug.
> Went I make, this is what I get:
>
> compat-wireless-2.6-old # make
> /root/compat-wireless-2.6-old/config.mk:30: *** "ERROR: There is a bug with compat-wireless on 2.6.22. Remove me if you want to fix me".  Stop.
>
> How can I fix it?

The error happens because config.mk checks for your kernel release and
if it detects its you are using a kernel release <= 2.6.22 it'll stop
and error out with that message. The problem is there is an oops
(kernel crash) that will occur if you enable the compile to go through
and use it. The error indicates to you that if you want to try to fix
the issue you can remove the force check on config.mk.

I used to support 2.6.22 but distributions have newer kernels so I
rather focus attention on newer kernels as we move forward. This gives
the opportunity for those developers interested in using 2.6.22 to go
ahead and fix it if they wish.

If you are a user I'd recommend to upgrade to at least 2.6.26.

  Luis

Re:

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Thu, 2009-03-19 at 07:03 +1100, David Thornton wrote:
> unsubscribe linux-wireless
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Try reading more closely.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re:

[Michael Buesch]

On Wednesday 22 April 2009 20:12:05 donpetrus@arcor.de wrote:
> 
> Hello, there is no possible to download  compat-wireless-2.6.tar.bz2 
> After clicking on it nothing happens -
> Thanks and best regards,
> Petrus

Please click harder.

-- 
Greetings, Michael.

Re:

[Gábor Stefanik]

On Thu, May 7, 2009 at 3:57 AM, waqas <waqas281@gmail.com> wrote:
> root@bt:~/Desktop/compat-wireless-2009-05-06# make install
>
> Your old wireless subsystem modules were left intact:
>
> /lib/modules/2.6.28.1/kernel/net/mac80211/mac80211.ko
> /lib/modules/2.6.28.1/kernel/net/wireless/cfg80211.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/adm8211.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/ath5k/ath5k.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/ath9k/ath9k.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/b43/b43.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/b43legacy/b43legacy=
=2Eko
> /lib/modules/2.6.28.1/kernel/drivers/net/usb/cdc_ether.ko
> /lib/modules/2.6.28.1/kernel/drivers/misc/eeprom_93cx6.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/ipw2100.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/ipw2200.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/iwlwifi/iwl3945.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/iwlwifi/iwlcore.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/libertas/libertas.k=
o
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/libertas/libertas_c=
s.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/libertas/libertas_s=
dio.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/libertas_tf/liberta=
s_tf.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/libertas_tf/liberta=
s_tf_usb.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/mac80211_hwsim.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/p54/p54common.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/p54/p54pci.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/p54/p54usb.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/usb/rndis_host.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rndis_wlan.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rt2x00/rt2400pci.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rt2x00/rt2500pci.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rt2x00/rt2500usb.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rt2x00/rt2x00lib.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rt2x00/rt2x00pci.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rt2x00/rt2x00usb.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rt2x00/rt61pci.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rt2x00/rt73usb.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rtl8180.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/rtl8187.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/libertas/usb8xxx.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/usb/usbnet.ko
> /lib/modules/2.6.28.1/kernel/drivers/net/wireless/zd1211rw/zd1211rw.k=
o
>
> make -C /lib/modules/2.6.28.1/build
> M=3D/root/Desktop/compat-wireless-2009-05-06 "INSTALL_MOD_DIR=3Dupdat=
es"
> \
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0modules_install
> make[1]: Entering directory `/usr/src/linux-source-2.6.28.1'
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/misc/eepr=
om/eeprom_93cx6.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/b44.k=
o
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/usb/c=
dc_ether.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/usb/r=
ndis_host.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/usb/u=
sbnet.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/adm8211.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/at76c50x-usb.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/ath/ath.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/ath/ath5k/ath5k.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/ath/ath9k/ath9k.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/b43/b43.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/b43legacy/b43legacy.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/ipw2x00/ipw2100.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/ipw2x00/ipw2200.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/ipw2x00/libipw.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/iwlwifi/iwl3945.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/iwlwifi/iwlagn.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/iwlwifi/iwlcore.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/libertas/libertas.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/libertas/libertas_cs.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/libertas/libertas_sdio.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/libertas/usb8xxx.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/libertas_tf/libertas_tf.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/libertas_tf/libertas_tf_usb.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/mac80211_hwsim.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/mwl8k.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/p54/p54common.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/p54/p54pci.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/p54/p54usb.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rndis_wlan.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt2400pci.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt2500pci.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt2500usb.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt2800usb.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt2x00lib.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt2x00pci.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt2x00usb.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt61pci.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rt2x00/rt73usb.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rtl818x/rtl8180.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/rtl818x/rtl8187.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/drivers/net/wirel=
ess/zd1211rw/zd1211rw.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/net/mac80211/mac8=
0211.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/net/wireless/cfg8=
0211.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/net/wireless/lib8=
0211.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/net/wireless/lib8=
0211_crypt_ccmp.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/net/wireless/lib8=
0211_crypt_tkip.ko
> =A0INSTALL /root/Desktop/compat-wireless-2009-05-06/net/wireless/lib8=
0211_crypt_wep.ko
> =A0DEPMOD =A02.6.28.1
> make[1]: Leaving directory `/usr/src/linux-source-2.6.28.1'
>
> Note: madwifi detected, we're going to disable it. If you would like
> to enable it later you can run:
> =A0 =A0sudo athenable madwifi
>
> Running athenable ath5k...
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
> [ERROR] Module is still being detected:
> /lib/modules/2.6.28.1/net/ath_pci.ko
> Disabling ath_pci ...mv: cannot stat
> `/lib/modules/2.6.28.1//lib/modules/2.6.28.1/net/ath_pci.ko': No such
> file or directory
>
>
>
> google search don't show up anything so only thing i can do is send b=
ug report.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wirel=
ess" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>

Try this patch:

--- scripts/modlib.sh.bak	2009-05-06 22:40:50.000000000 +0200
+++ scripts/modlib.sh	2009-05-06 22:40:31.000000000 +0200
 -38,7 +38,7 @@ function module_disable {
 		else
 			echo -en "Disabling $MODULE ..."
 		fi
-		mv -f /lib/modules/$VER/$CHECK /lib/modules/$VER/${CHECK}${IGNORE_SU=
=46FIX}
+		mv -f $CHECK ${CHECK}${IGNORE_SUFFIX}
 		depmod -ae
 		CHECK_AGAIN=3D`modprobe -l $MODULE`
 		if [ "$CHECK" !=3D "$CHECK_AGAIN" ]; then

(pastebin address if this mail is linewrapped: http://pastebin.com/f233=
42312)

--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Andrey Yurovsky]

MjAwOS81LzE3IFdsYWRpbWlyIEhpcm5paiA8Y291bnRlci1zdHJpa2VAYmsucnU+Ogo+IPrE0sHX
09TX1crUxS4KPiD0wcvB0SDQ0s/CzMXNwSBzbGFja3dhcmUgMTIuMiCa0cTSzyAyLjYuMjcgzsUg
zc/H1SDV09TBzs/XydTYIMTSwcrXxdLBIM7BIHdpZmkgcnRsODE4N3NlLgo+IO/exc7YINDSz9vV
INDPzc/e2CDF08zJINzUzyDXz9rNz9bOzy4KPiDl08zJINzUzyDXz9rNz9bOzyDUzyDQz9bBzNXK
09TBINDPxNLPws7PIM/QydvJ1MUgy8HLINzUzyDExczB1Ngg09nMy8HNySDOwSDE0sHK18XSwSDJ
IMTP0M/MzsnU0sXM2M7ZxSDQwcvF1NkgKMkgy8HLIMnIINXT1MHOz9fJ1NgpLgo+IGFwdC1nZXQg
zsXU1SgKPiDT1M/J1CBzbGFwdC1nZXQgzsXazsHAIMvByyDJzSDQz8zY2s/XwdTY09EuCj4g+sHS
wc7FxSDT0MHTycLPLgoKVGhlIHJ0bDgxODdzZSBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBtYWlu
bGluZSBkcml2ZXIuICBUaGVyZSdzIGEKZHJpdmVyIGZvciBpdCBpbiBzdGFnaW5nIHRob3VnaCwg
YW5kIHRoZXJlJ3MgYSB2ZW5kb3IgZHJpdmVyIGhvc3RlZApoZXJlOgpodHRwOi8vY29kZS5nb29n
bGUuY29tL3AvbXNpLXdpbmQtbGludXgvCi4uLkkgd291bGQgdHJ5IHRvIGJ1aWxkIGFuZCBsb2Fk
IHRoYXQgZHJpdmVyIGZvciBub3cuCgogIC1BbmRyZXkK

Re:

[Gábor Stefanik]

Decoded version:

The rtl8187se is not supported by the mainline driver.  There's a
driver for it in staging though, and there's a vendor driver hosted
here:
http://code.google.com/p/msi-wind-linux/
...I would try to build and load that driver for now.

  -Andrey

2009/5/19 Andrey Yurovsky <yurovsky@gmail.com>:
> MjAwOS81LzE3IFdsYWRpbWlyIEhpcm5paiA8Y291bnRlci1zdHJpa2VAYmsucnU+Ogo+IPrE0sHX
> 09TX1crUxS4KPiD0wcvB0SDQ0s/CzMXNwSBzbGFja3dhcmUgMTIuMiCa0cTSzyAyLjYuMjcgzsUg
> zc/H1SDV09TBzs/XydTYIMTSwcrXxdLBIM7BIHdpZmkgcnRsODE4N3NlLgo+IO/exc7YINDSz9vV
> INDPzc/e2CDF08zJINzUzyDXz9rNz9bOzy4KPiDl08zJINzUzyDXz9rNz9bOzyDUzyDQz9bBzNXK
> 09TBINDPxNLPws7PIM/QydvJ1MUgy8HLINzUzyDExczB1Ngg09nMy8HNySDOwSDE0sHK18XSwSDJ
> IMTP0M/MzsnU0sXM2M7ZxSDQwcvF1NkgKMkgy8HLIMnIINXT1MHOz9fJ1NgpLgo+IGFwdC1nZXQg
> zsXU1SgKPiDT1M/J1CBzbGFwdC1nZXQgzsXazsHAIMvByyDJzSDQz8zY2s/XwdTY09EuCj4g+sHS
> wc7FxSDT0MHTycLPLgoKVGhlIHJ0bDgxODdzZSBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBtYWlu
> bGluZSBkcml2ZXIuICBUaGVyZSdzIGEKZHJpdmVyIGZvciBpdCBpbiBzdGFnaW5nIHRob3VnaCwg
> YW5kIHRoZXJlJ3MgYSB2ZW5kb3IgZHJpdmVyIGhvc3RlZApoZXJlOgpodHRwOi8vY29kZS5nb29n
> bGUuY29tL3AvbXNpLXdpbmQtbGludXgvCi4uLkkgd291bGQgdHJ5IHRvIGJ1aWxkIGFuZCBsb2Fk
> IHRoYXQgZHJpdmVyIGZvciBub3cuCgogIC1BbmRyZXkK
-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re:

[Larry Finger]

Gábor Stefanik wrote:
> Decoded version:
> 
> The rtl8187se is not supported by the mainline driver.  There's a
> driver for it in staging though, and there's a vendor driver hosted
> here:
> http://code.google.com/p/msi-wind-linux/
> ...I would try to build and load that driver for now.

The driver in staging _IS_ the vendor driver with a leak in the procfs fixed and
the code brought up to the latest kernels. It will work. There is no need to use
the vendor driver and to redo those fixes.

I am working on an rtl8187se driver that uses mac80211 and that will be suitable
to be included in mainline kernels. I estimate that I am about 25% done.

Larry

Re:

[Janakiram Sistla]

I will be resending this patch ...sorry subjet line missing in this
sorry about that

Regards,
Ram.
On Wed, Nov 18, 2009 at 7:20 AM, Janakiram Sistla
<janakiram.sistla@gmail.com> wrote:
> From: Janakiram Sistla <janakiram.sistla@gmail.com>
>
> Adding radio type FM in RFKILL_TYPE_.FM belongs to
> same class of with both TX/RX capability
>
> Signed-off-by: Janakiram Sistla <janakiram.sistla@gmail.com>
> ---
>  include/linux/rfkill.h |    2 ++
>  net/rfkill/core.c      |    2 ++
>  2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
> index 3392c59..7ae75ef 100644
> --- a/include/linux/rfkill.h
> +++ b/include/linux/rfkill.h
> @@ -35,6 +35,7 @@
>  * @RFKILL_TYPE_UWB: switch is on a ultra wideband device.
>  * @RFKILL_TYPE_WIMAX: switch is on a WiMAX device.
>  * @RFKILL_TYPE_WWAN: switch is on a wireless WAN device.
> + * @RFKILL_TYPE_FM: switch is on a wireless FM device.
>  * @NUM_RFKILL_TYPES: number of defined rfkill types
>  */
>  enum rfkill_type {
> @@ -44,6 +45,7 @@ enum rfkill_type {
>        RFKILL_TYPE_UWB,
>        RFKILL_TYPE_WIMAX,
>        RFKILL_TYPE_WWAN,
> +       RFKILL_TYPE_FM,
>        RFKILL_TYPE_GPS,
>        NUM_RFKILL_TYPES,
>  };
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index ba2efb9..61b716e 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -590,6 +590,8 @@ static const char *rfkill_get_type_str(enum rfkill_type type)
>                return "wimax";
>        case RFKILL_TYPE_WWAN:
>                return "wwan";
> +       case RFKILL_TYPE_FM:
> +               return "fm";
>        case RFKILL_TYPE_GPS:
>                return "gps";
>        default:
> --
> 1.5.4.3
>
>

Re:

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

On Wed, 2009-11-18 at 07:20 +0530, Janakiram Sistla wrote:

> ---
>  include/linux/rfkill.h |    2 ++
>  net/rfkill/core.c      |    2 ++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
> index 3392c59..7ae75ef 100644
> --- a/include/linux/rfkill.h
> +++ b/include/linux/rfkill.h
> @@ -35,6 +35,7 @@
>   * @RFKILL_TYPE_UWB: switch is on a ultra wideband device.
>   * @RFKILL_TYPE_WIMAX: switch is on a WiMAX device.
>   * @RFKILL_TYPE_WWAN: switch is on a wireless WAN device.
> + * @RFKILL_TYPE_FM: switch is on a wireless FM device.
>   * @NUM_RFKILL_TYPES: number of defined rfkill types
>   */
>  enum rfkill_type {
> @@ -44,6 +45,7 @@ enum rfkill_type {
>  	RFKILL_TYPE_UWB,
>  	RFKILL_TYPE_WIMAX,
>  	RFKILL_TYPE_WWAN,
> +	RFKILL_TYPE_FM,
>  	RFKILL_TYPE_GPS,
>  	NUM_RFKILL_TYPES,
>  };

Nice try, but no fly. This struct is ABI, you cannot add in the middle.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re:

[Janakiram Sistla]

On Wed, Nov 18, 2009 at 4:23 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-11-18 at 07:20 +0530, Janakiram Sistla wrote:
>
>> ---
>>  include/linux/rfkill.h |    2 ++
>>  net/rfkill/core.c      |    2 ++
>>  2 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
>> index 3392c59..7ae75ef 100644
>> --- a/include/linux/rfkill.h
>> +++ b/include/linux/rfkill.h
>> @@ -35,6 +35,7 @@
>>   * @RFKILL_TYPE_UWB: switch is on a ultra wideband device.
>>   * @RFKILL_TYPE_WIMAX: switch is on a WiMAX device.
>>   * @RFKILL_TYPE_WWAN: switch is on a wireless WAN device.
>> + * @RFKILL_TYPE_FM: switch is on a wireless FM device.
>>   * @NUM_RFKILL_TYPES: number of defined rfkill types
>>   */
>>  enum rfkill_type {
>> @@ -44,6 +45,7 @@ enum rfkill_type {
>>       RFKILL_TYPE_UWB,
>>       RFKILL_TYPE_WIMAX,
>>       RFKILL_TYPE_WWAN,
>> +     RFKILL_TYPE_FM,
>>       RFKILL_TYPE_GPS,
>>       NUM_RFKILL_TYPES,
>>  };
>
> Nice try, but no fly. This struct is ABI, you cannot add in the middle.
Is it ok if i can add my change after RFKILL_TYPE_GPS.But with respect
to the change i made i also made the necessary changes in core.c.

>
> johannes
>

Re:

[John W. Linville]

On Wed, Nov 18, 2009 at 11:53:51AM +0100, Johannes Berg wrote:
> On Wed, 2009-11-18 at 07:20 +0530, Janakiram Sistla wrote:
> 
> > ---
> >  include/linux/rfkill.h |    2 ++
> >  net/rfkill/core.c      |    2 ++
> >  2 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
> > index 3392c59..7ae75ef 100644
> > --- a/include/linux/rfkill.h
> > +++ b/include/linux/rfkill.h
> > @@ -35,6 +35,7 @@
> >   * @RFKILL_TYPE_UWB: switch is on a ultra wideband device.
> >   * @RFKILL_TYPE_WIMAX: switch is on a WiMAX device.
> >   * @RFKILL_TYPE_WWAN: switch is on a wireless WAN device.
> > + * @RFKILL_TYPE_FM: switch is on a wireless FM device.
> >   * @NUM_RFKILL_TYPES: number of defined rfkill types
> >   */
> >  enum rfkill_type {
> > @@ -44,6 +45,7 @@ enum rfkill_type {
> >  	RFKILL_TYPE_UWB,
> >  	RFKILL_TYPE_WIMAX,
> >  	RFKILL_TYPE_WWAN,
> > +	RFKILL_TYPE_FM,
> >  	RFKILL_TYPE_GPS,
> >  	NUM_RFKILL_TYPES,
> >  };
> 
> Nice try, but no fly. This struct is ABI, you cannot add in the middle.

Ah, good point -- I think I may have inadvertently encourage this
order. :-(

It looks like you'll need the other order -- be mindful of the
BUILD_BUG_ON I pointed-out in the previous email!

John

P.S.  Hmmm...anyone want to add a kerneldoc entry for RFKILL_TYPE_GPS?
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re:

[Janakiram Sistla]

On Wed, Nov 18, 2009 at 7:14 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Wed, Nov 18, 2009 at 11:53:51AM +0100, Johannes Berg wrote:
>> On Wed, 2009-11-18 at 07:20 +0530, Janakiram Sistla wrote:
>>
>> > ---
>> >  include/linux/rfkill.h |    2 ++
>> >  net/rfkill/core.c      |    2 ++
>> >  2 files changed, 4 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
>> > index 3392c59..7ae75ef 100644
>> > --- a/include/linux/rfkill.h
>> > +++ b/include/linux/rfkill.h
>> > @@ -35,6 +35,7 @@
>> >   * @RFKILL_TYPE_UWB: switch is on a ultra wideband device.
>> >   * @RFKILL_TYPE_WIMAX: switch is on a WiMAX device.
>> >   * @RFKILL_TYPE_WWAN: switch is on a wireless WAN device.
>> > + * @RFKILL_TYPE_FM: switch is on a wireless FM device.
>> >   * @NUM_RFKILL_TYPES: number of defined rfkill types
>> >   */
>> >  enum rfkill_type {
>> > @@ -44,6 +45,7 @@ enum rfkill_type {
>> >     RFKILL_TYPE_UWB,
>> >     RFKILL_TYPE_WIMAX,
>> >     RFKILL_TYPE_WWAN,
>> > +   RFKILL_TYPE_FM,
>> >     RFKILL_TYPE_GPS,
>> >     NUM_RFKILL_TYPES,
>> >  };
>>
>> Nice try, but no fly. This struct is ABI, you cannot add in the middle.
>
> Ah, good point -- I think I may have inadvertently encourage this
> order. :-(
>
> It looks like you'll need the other order -- be mindful of the
> BUILD_BUG_ON I pointed-out in the previous email!
>
> John
>
> P.S.  Hmmm...anyone want to add a kerneldoc entry for RFKILL_TYPE_GPS?
Can i add this ???
> --
> John W. Linville                Someday the world will need a hero, and you
> linville@tuxdriver.com                  might be all we have.  Be ready.
>

Re:

[John W. Linville]

On Wed, Nov 18, 2009 at 07:49:30PM +0530, Janakiram Sistla wrote:
> On Wed, Nov 18, 2009 at 7:14 PM, John W. Linville

> > P.S.  Hmmm...anyone want to add a kerneldoc entry for RFKILL_TYPE_GPS?
> Can i add this ???

Sure, but please do a different patch for that.  Make it the first
one, so that it can be applied even if there is still a problem with
the other patch.

Thanks,

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re:

[Gábor Stefanik]

On Sat, Mar 13, 2010 at 5:33 PM, Thijs van der Kraan
<thijsvanderkraan@telfort.nl> wrote:
> The zd1211rw does not work with the Shuttle PN15G (D-Link Corp. WL54).
> After the driver fails it also break the device for my windows XP
> install.
> To get it back in working order I have to physically re-plug it while
> windows is running, this is pretty annoying as the PN15G is meant to be,
> and is, built inside my shuttle box.
>
> I tried another device that uses the same driver, the ZyAIR G-220, and
> it works like a charm.
>
> - Is there a way to get the Shuttle PN15G working ?
> - Can prevent the driver from breaking my device, so it will remain
> working under windows XP.
>
>
> Thijs van de Kraan
>
>
> lsusb:
> ---------------
> Bus 001 Device 004: ID 0586:3401 ZyXEL Communications Corp. ZyAIR G-220
> Bus 001 Device 003: ID 07b8:6001 D-Link Corp. WL54
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 002: ID 04fc:05d8 Sunplus Technology Co., Ltd
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> ---------------
>
> dmesg (Shuttle PN15G):
> ---------------
> [    9.419022] zd1211rw 1-8:1.0: phy0
> [    9.419050] usbcore: registered new interface driver zd1211rw
> [   11.618783] usb 1-8: firmware: requesting zd1211/zd1211b_ub
> [   11.979913] usb 1-8: firmware version 0x4810 and device bootcode
> version 0x4721 differ
> [   11.979919] usb 1-8: firmware: requesting zd1211/zd1211b_ur
> [   12.184918] usb 1-8: firmware: requesting zd1211/zd1211b_uphr
> [   12.261522] zd1211rw 1-8:1.0: RF2959 is currently not supported for
> ZD1211B devices

Are you sure this is a ZD1211B, not a regular ZD1211? Try changing the
USB ID definitions to mark this as a ZD1211.

> [   12.263744] eth0: link down
> [   12.263950] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   14.491044] usb 1-8: firmware: requesting zd1211/zd1211b_ub
> [   14.496834] usb 1-8: firmware version 0x4810 and device bootcode
> version 0x4721 differ
> [   14.496841] usb 1-8: firmware: requesting zd1211/zd1211b_ur
> [   15.526035] usb 1-8: USB control request for firmware upload failed.
> Error number -110
> [   15.526049] zd1211rw 1-8:1.0: couldn't load firmware. Error number
> -110
>
> dmesg (ZyAIR G-220):
> ---------------
>
> [  283.920025] usb 1-4: new high speed USB device using ehci_hcd and
> address 4
> [  284.070953] usb 1-4: configuration #1 chosen from 1 choice
> [  284.200081] usb 1-4: reset high speed USB device using ehci_hcd and
> address 4
> [  284.351553] phy1: Selected rate control algorithm 'minstrel'
> [  284.352966] zd1211rw 1-4:1.0: phy1
> [  284.387607] usb 1-4: firmware: requesting zd1211/zd1211_ub
> [  284.422786] usb 1-4: firmware version 0x4330 and device bootcode
> version 0x4810 differ
> [  284.422796] usb 1-4: firmware: requesting zd1211/zd1211_ur
> [  284.446550] usb 1-4: firmware: requesting zd1211/zd1211_uphr
> [  284.528039] zd1211rw 1-4:1.0: firmware version 4605
> [  284.568044] zd1211rw 1-4:1.0: zd1211 chip 0586:3401 v4810 high
> 00-13-49 AL2230_RF pa0 -----
> [  284.570691] cfg80211: Calling CRDA for country: DE
> [  284.574176] cfg80211: Regulatory domain changed to country: DE
> [  284.574184]  (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> [  284.574190]  (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  284.574195]  (5150000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> [  284.574200]  (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
> [  284.589627] ADDRCONF(NETDEV_UP): wlan1: link is not ready
> [  291.145078] wlan1: authenticate with AP 00:21:29:8b:3a:49
> [  291.146703] wlan1: authenticated
> [  291.146708] wlan1: associate with AP 00:21:29:8b:3a:49
> [  291.148944] wlan1: RX AssocResp from 00:21:29:8b:3a:49 (capab=0x411
> status=0 aid=2)
> [  291.148950] wlan1: associated
> [  291.149928] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
> [  301.720021] wlan1: no IPv6 routers present
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

(no subject)

[Vasil Lalov]

Hello,

I am seeing some weird behavior with the iwlagn driver from linuxwireless.com:

My Intel 5300 wireless card will randomly disassociate itself from the
access point. It happens with or without security enabled. It only
happens when using the 802.11n mode. I've noticed that the further
away I am from the AP, the LOWER the chances of this to happen. If I
put my laptop within 2-3 feet from the access point, the wireless card
will disassociate itself on average once every 30 seconds.

Here is some data:

uname -a
Linux red 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:02:26 UTC 2010
x86_64 GNU/Linux

filename:
/lib/modules/2.6.31-20-generic/updates/drivers/net/wireless/iwlwifi/iwlagn.ko
alias:          iwl4965
license:        GPL
author:         Copyright(c) 2003-2010 Intel Corporation <ilw@linux.intel.com>
version:        in-tree:
description:    Intel(R) Wireless WiFi Link AGN driver for Linux
firmware:       iwlwifi-4965-2.ucode
firmware:       iwlwifi-5150-2.ucode
firmware:       iwlwifi-5000-2.ucode
firmware:       iwlwifi-6050-4.ucode
firmware:       iwlwifi-6000-4.ucode
firmware:       iwlwifi-1000-3.ucode
srcversion:     10AEF71B7C48925A15AC101
alias:          pci:v00008086d00000084sv*sd00001316bc*sc*i*
alias:          pci:v00008086d00000084sv*sd00001216bc*sc*i*
alias:          pci:v00008086d00000083sv*sd00001326bc*sc*i*
alias:          pci:v00008086d00000083sv*sd00001226bc*sc*i*
alias:          pci:v00008086d00000083sv*sd00001306bc*sc*i*
alias:          pci:v00008086d00000083sv*sd00001206bc*sc*i*
alias:          pci:v00008086d00000084sv*sd00001315bc*sc*i*
alias:          pci:v00008086d00000084sv*sd00001215bc*sc*i*
alias:          pci:v00008086d00000083sv*sd00001325bc*sc*i*
alias:          pci:v00008086d00000083sv*sd00001225bc*sc*i*
alias:          pci:v00008086d00000083sv*sd00001305bc*sc*i*
alias:          pci:v00008086d00000083sv*sd00001205bc*sc*i*
alias:          pci:v00008086d00000089sv*sd00001316bc*sc*i*
alias:          pci:v00008086d00000089sv*sd00001311bc*sc*i*
alias:          pci:v00008086d00000087sv*sd00001326bc*sc*i*
alias:          pci:v00008086d00000087sv*sd00001321bc*sc*i*
alias:          pci:v00008086d00000087sv*sd00001306bc*sc*i*
alias:          pci:v00008086d00000087sv*sd00001301bc*sc*i*
alias:          pci:v00008086d00004239sv*sd00001316bc*sc*i*
alias:          pci:v00008086d00004239sv*sd00001311bc*sc*i*
alias:          pci:v00008086d00004238sv*sd00001111bc*sc*i*
alias:          pci:v00008086d0000422Csv*sd00001326bc*sc*i*
alias:          pci:v00008086d0000422Csv*sd00001321bc*sc*i*
alias:          pci:v00008086d0000422Csv*sd00001307bc*sc*i*
alias:          pci:v00008086d0000422Csv*sd00001306bc*sc*i*
alias:          pci:v00008086d0000422Csv*sd00001301bc*sc*i*
alias:          pci:v00008086d0000422Bsv*sd00001121bc*sc*i*
alias:          pci:v00008086d0000422Bsv*sd00001101bc*sc*i*
alias:          pci:v00008086d0000423Dsv*sd00001316bc*sc*i*
alias:          pci:v00008086d0000423Dsv*sd00001216bc*sc*i*
alias:          pci:v00008086d0000423Dsv*sd00001311bc*sc*i*
alias:          pci:v00008086d0000423Dsv*sd00001211bc*sc*i*
alias:          pci:v00008086d0000423Csv*sd00001321bc*sc*i*
alias:          pci:v00008086d0000423Csv*sd00001221bc*sc*i*
alias:          pci:v00008086d0000423Csv*sd00001306bc*sc*i*
alias:          pci:v00008086d0000423Csv*sd00001206bc*sc*i*
alias:          pci:v00008086d0000423Csv*sd00001301bc*sc*i*
alias:          pci:v00008086d0000423Csv*sd00001201bc*sc*i*
alias:          pci:v00008086d0000423Bsv*sd00001011bc*sc*i*
alias:          pci:v00008086d0000423Asv*sd00001021bc*sc*i*
alias:          pci:v00008086d0000423Asv*sd00001001bc*sc*i*
alias:          pci:v00008086d00004236sv*sd00001114bc*sc*i*
alias:          pci:v00008086d00004236sv*sd00001014bc*sc*i*
alias:          pci:v00008086d00004236sv*sd00001111bc*sc*i*
alias:          pci:v00008086d00004236sv*sd00001011bc*sc*i*
alias:          pci:v00008086d00004235sv*sd00001104bc*sc*i*
alias:          pci:v00008086d00004235sv*sd00001004bc*sc*i*
alias:          pci:v00008086d00004235sv*sd00001101bc*sc*i*
alias:          pci:v00008086d00004235sv*sd00001001bc*sc*i*
alias:          pci:v00008086d00004235sv*sd00001124bc*sc*i*
alias:          pci:v00008086d00004235sv*sd00001024bc*sc*i*
alias:          pci:v00008086d00004235sv*sd00001121bc*sc*i*
alias:          pci:v00008086d00004235sv*sd00001021bc*sc*i*
alias:          pci:v00008086d00004237sv*sd00001316bc*sc*i*
alias:          pci:v00008086d00004237sv*sd00001216bc*sc*i*
alias:          pci:v00008086d00004237sv*sd00001315bc*sc*i*
alias:          pci:v00008086d00004237sv*sd00001215bc*sc*i*
alias:          pci:v00008086d00004237sv*sd00001314bc*sc*i*
alias:          pci:v00008086d00004237sv*sd00001214bc*sc*i*
alias:          pci:v00008086d00004237sv*sd00001311bc*sc*i*
alias:          pci:v00008086d00004237sv*sd00001211bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001326bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001226bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001325bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001225bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001324bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001224bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001321bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001221bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001306bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001206bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001305bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001205bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001304bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001204bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001301bc*sc*i*
alias:          pci:v00008086d00004232sv*sd00001201bc*sc*i*
alias:          pci:v00008086d00004230sv*sd*bc*sc*i*
alias:          pci:v00008086d00004229sv*sd*bc*sc*i*
depends:        iwlcore,mac80211,compat_firmware_class,cfg80211
vermagic:       2.6.31-20-generic SMP mod_unload modversions
parm:           swcrypto50:using software crypto engine (default 0 [hardware])
 (bool)
parm:           queues_num50:number of hw queues in 50xx series (int)
parm:           11n_disable50:disable 50XX 11n functionality (int)
parm:           amsdu_size_8K50:enable 8K amsdu size in 50XX series (int)
parm:           fw_restart50:restart firmware in case of error (int)
parm:           antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm:           swcrypto:using crypto in software (default 0 [hardware]) (int)
parm:           disable_hw_scan:disable hardware scanning (default 0) (int)
parm:           queues_num:number of hw queues. (int)
parm:           11n_disable:disable 11n functionality (int)
parm:           amsdu_size_8K:enable 8K amsdu size (int)
parm:           fw_restart4965:restart firmware in case of error (int)


The error messages in dmesg:

iwlagn 0000:0c:00.0: Microcode SW error detected.  Restarting 0x2000000.
[40595.037808] iwlagn 0000:0c:00.0: Start IWL Error Log Dump:
[40595.037814] iwlagn 0000:0c:00.0: Status: 0x000212E4, count: 5
[40595.037945] iwlagn 0000:0c:00.0: Desc
Time       data1      data2      line
[40595.037954] iwlagn 0000:0c:00.0: NMI_INTERRUPT_WDG            (#04)
3570070946 0x00000002 0x07030000 3664
[40595.037960] iwlagn 0000:0c:00.0: blink1  blink2  ilink1  ilink2
[40595.037966] iwlagn 0000:0c:00.0: 0x005AA 0x006E8 0x008B2 0x02294
[40595.037972] iwlagn 0000:0c:00.0: CSR values:
[40595.037976] iwlagn 0000:0c:00.0: (2nd byte of CSR_INT_COALESCING is
CSR_INT_PERIODIC_REG)
[40595.037986] iwlagn 0000:0c:00.0:        CSR_HW_IF_CONFIG_REG: 0X00480301
[40595.037994] iwlagn 0000:0c:00.0:          CSR_INT_COALESCING: 0X00000040
[40595.038003] iwlagn 0000:0c:00.0:                     CSR_INT: 0X04000000
[40595.038012] iwlagn 0000:0c:00.0:                CSR_INT_MASK: 0X00000000
[40595.038020] iwlagn 0000:0c:00.0:           CSR_FH_INT_STATUS: 0X00000000
[40595.038029] iwlagn 0000:0c:00.0:                 CSR_GPIO_IN: 0X00000000
[40595.038037] iwlagn 0000:0c:00.0:                   CSR_RESET: 0X00000000
[40595.038046] iwlagn 0000:0c:00.0:                CSR_GP_CNTRL: 0X080403c5
[40595.038054] iwlagn 0000:0c:00.0:                  CSR_HW_REV: 0X00000024
[40595.038062] iwlagn 0000:0c:00.0:              CSR_EEPROM_REG: 0X00000000
[40595.038071] iwlagn 0000:0c:00.0:               CSR_EEPROM_GP: 0X90000004
[40595.038079] iwlagn 0000:0c:00.0:              CSR_OTP_GP_REG: 0X00060000
[40595.038088] iwlagn 0000:0c:00.0:                 CSR_GIO_REG: 0X00080046
[40595.038096] iwlagn 0000:0c:00.0:            CSR_GP_UCODE_REG: 0X00004547
[40595.038104] iwlagn 0000:0c:00.0:           CSR_GP_DRIVER_REG: 0X00000000
[40595.038112] iwlagn 0000:0c:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
[40595.038121] iwlagn 0000:0c:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
[40595.038129] iwlagn 0000:0c:00.0:                 CSR_LED_REG: 0X00000058
[40595.038138] iwlagn 0000:0c:00.0:        CSR_DRAM_INT_TBL_REG: 0X88110576
[40595.038146] iwlagn 0000:0c:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
[40595.038154] iwlagn 0000:0c:00.0:             CSR_ANA_PLL_CFG: 0X00880300
[40595.038163] iwlagn 0000:0c:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
[40595.038171] iwlagn 0000:0c:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0000
[40595.038176] iwlagn 0000:0c:00.0: FH register values:
[40595.038194] iwlagn 0000:0c:00.0:
FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X1100a800
[40595.038212] iwlagn 0000:0c:00.0:
FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X01105640
[40595.038231] iwlagn 0000:0c:00.0:
FH_RSCSR_CHNL0_WPTR: 0X00000078
[40595.038249] iwlagn 0000:0c:00.0:
FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
[40595.038267] iwlagn 0000:0c:00.0:
FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
[40595.038286] iwlagn 0000:0c:00.0:
FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
[40595.038304] iwlagn 0000:0c:00.0:
FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
[40595.038322] iwlagn 0000:0c:00.0:
FH_TSSR_TX_STATUS_REG: 0X07ff0001
[40595.038340] iwlagn 0000:0c:00.0:
FH_TSSR_TX_ERROR_REG: 0X00000000
[40595.038402] iwlagn 0000:0c:00.0: Start IWL Event Log Dump: display
last 20 entries
[40595.038426] iwlagn 0000:0c:00.0: EVT_LOGT:2749976970:0x0000010f:0106
[40595.038441] iwlagn 0000:0c:00.0: EVT_LOGT:2749976972:0x00000000:0301
[40595.038456] iwlagn 0000:0c:00.0: EVT_LOGT:2749977046:0x00000261:0353
[40595.038471] iwlagn 0000:0c:00.0: EVT_LOGT:2749977367:0x0000010f:0106
[40595.038485] iwlagn 0000:0c:00.0: EVT_LOGT:2749977369:0x00000000:0302
[40595.038500] iwlagn 0000:0c:00.0: EVT_LOGT:2749977395:0x00000436:0323
[40595.038515] iwlagn 0000:0c:00.0: EVT_LOGT:2749977417:0x00000000:1350
[40595.038530] iwlagn 0000:0c:00.0: EVT_LOGT:2749977418:0x00000000:1351
[40595.038545] iwlagn 0000:0c:00.0: EVT_LOGT:2749977418:0x00000001:1352
[40595.038559] iwlagn 0000:0c:00.0: EVT_LOGT:2749977419:0x00000002:1353
[40595.038575] iwlagn 0000:0c:00.0: EVT_LOGT:2749977474:0x000000d4:0322
[40595.038590] iwlagn 0000:0c:00.0: EVT_LOGT:2749977641:0x0000010f:0106
[40595.038604] iwlagn 0000:0c:00.0: EVT_LOGT:2749977642:0x00000000:0302
[40595.038619] iwlagn 0000:0c:00.0: EVT_LOGT:2749977668:0x00000436:0323
[40595.038634] iwlagn 0000:0c:00.0: EVT_LOGT:2749977690:0x00000000:1350
[40595.038649] iwlagn 0000:0c:00.0: EVT_LOGT:2749977690:0x00000000:1351
[40595.038664] iwlagn 0000:0c:00.0: EVT_LOGT:2749977691:0x00000001:1352
[40595.038678] iwlagn 0000:0c:00.0: EVT_LOGT:2749977691:0x00000002:1353
[40595.038693] iwlagn 0000:0c:00.0: EVT_LOGT:2750177633:0x000000d7:0123
[40595.038708] iwlagn 0000:0c:00.0: EVT_LOGT:2750177641:0x00000000:0125
[40595.101312] iwlagn 0000:0c:00.0: Stopping AGG while state not ON or starting
[40595.101318] iwlagn 0000:0c:00.0: queue number out of range: 0, must
be 10 to 19
[40595.101340] iwlagn 0000:0c:00.0: Stopping AGG while state not ON or starting
[40595.101343] iwlagn 0000:0c:00.0: queue number out of range: 0, must
be 10 to 19
[40595.146001] iwlagn 0000:0c:00.0: iwl_tx_agg_start on ra =
00:26:5a:f5:73:3a tid = 0
[40600.324551] iwlagn 0000:0c:00.0: iwl_tx_agg_start on ra =
00:26:5a:f5:73:3a tid = 0
[40600.540126] No probe response from AP 00:26:5a:f5:73:3a after
500ms, disconnecting.
[40600.572606] mac80211-phy0: failed to remove key (0,
00:26:5a:f5:73:3a) from hardware (-22)
[40600.640467] cfg80211: All devices are disconnected, going to
restore regulatory settings
[40600.640481] cfg80211: Restoring regulatory settings
[40600.640489] cfg80211: Calling CRDA to update world regulatory domain
[40600.653155] cfg80211: World regulatory domain updated:
[40600.653163]     (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[40600.653170]     (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[40600.653177]     (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[40600.653183]     (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[40600.653190]     (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[40600.653196]     (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[40620.132020] wlan0: authenticate with 00:26:5a:f5:73:3a (try 1)
[40620.137290] wlan0: authenticated
[40620.137341] wlan0: associate with 00:26:5a:f5:73:3a (try 1)
[40620.142828] wlan0: RX AssocResp from 00:26:5a:f5:73:3a (capab=0x431
status=0 aid=1)
[40620.142832] wlan0: associated
[40622.631049] iwlagn 0000:0c:00.0: iwl_tx_agg_start on ra =
00:26:5a:f5:73:3a tid = 0


Any suggestions?

Re:

[reinette chatre]

On Wed, 2010-03-17 at 06:13 -0700, Vasil Lalov wrote:

> The error messages in dmesg:
> 
> iwlagn 0000:0c:00.0: Microcode SW error detected.  Restarting 0x2000000.
> [40595.037808] iwlagn 0000:0c:00.0: Start IWL Error Log Dump:
> [40595.037814] iwlagn 0000:0c:00.0: Status: 0x000212E4, count: 5
> [40595.037945] iwlagn 0000:0c:00.0: Desc
> Time       data1      data2      line
> [40595.037954] iwlagn 0000:0c:00.0: NMI_INTERRUPT_WDG            (#04)
> 3570070946 0x00000002 0x07030000 3664

[...]

> [40595.101312] iwlagn 0000:0c:00.0: Stopping AGG while state not ON or starting
> [40595.101318] iwlagn 0000:0c:00.0: queue number out of range: 0, must
> be 10 to 19
> [40595.101340] iwlagn 0000:0c:00.0: Stopping AGG while state not ON or starting
> [40595.101343] iwlagn 0000:0c:00.0: queue number out of range: 0, must
> be 10 to 19

This looks similar to https://bugzilla.kernel.org/show_bug.cgi?id=15374
- could you please update your kernel to 2.6.33 and try the patches
attached to that bug report?

Reinette

Re:

[Vasil Lalov]

Reinett,

Thanks for responding to this. I also noticed other things. It seems
that this Microcode SW error occurs because the wifi card is
overheating. When used in n-mode and there is a large file transfer,
the temperature of the card rises to over 62C. Soon after this, the
microcode error occurs and the card gets disassociated.

Doing more research on the power vs temperature problem, I discovered
that other users are seeing this as well. Some have solved their
problem by enabling the power management for the wifi card by issuing

iwconfig wlan0 power on

Others, completely disabled the power management and forced a fixed,
lower power level by issuing

 echo 8 > /sys/bus/pci/drivers/iwlagn/0000\:06\:00.0/power_level

Also, what I have noticed is that if I have my laptop very very close
to the Access Point (1-3 feet) then this error is more likely to
happen. If I move the laptop further away, say more than 15-20 feet,
this error stops occurring so frequently.

Unfortunately, I cannot upgrade to 2.6.33 kernel as it is currently
not available for my distribution and I am reluctant to recompile my
own kernel.

Vasil

===
Vasil Lalov
Sr. Systems Manager
Chicago Public Library


On Fri, Mar 19, 2010 at 1:05 AM, reinette chatre
<reinette.chatre@intel.com> wrote:
> On Wed, 2010-03-17 at 06:13 -0700, Vasil Lalov wrote:
>
>> The error messages in dmesg:
>>
>> iwlagn 0000:0c:00.0: Microcode SW error detected.  Restarting 0x2000000.
>> [40595.037808] iwlagn 0000:0c:00.0: Start IWL Error Log Dump:
>> [40595.037814] iwlagn 0000:0c:00.0: Status: 0x000212E4, count: 5
>> [40595.037945] iwlagn 0000:0c:00.0: Desc
>> Time       data1      data2      line
>> [40595.037954] iwlagn 0000:0c:00.0: NMI_INTERRUPT_WDG            (#04)
>> 3570070946 0x00000002 0x07030000 3664
>
> [...]
>
>> [40595.101312] iwlagn 0000:0c:00.0: Stopping AGG while state not ON or starting
>> [40595.101318] iwlagn 0000:0c:00.0: queue number out of range: 0, must
>> be 10 to 19
>> [40595.101340] iwlagn 0000:0c:00.0: Stopping AGG while state not ON or starting
>> [40595.101343] iwlagn 0000:0c:00.0: queue number out of range: 0, must
>> be 10 to 19
>
> This looks similar to https://bugzilla.kernel.org/show_bug.cgi?id=15374
> - could you please update your kernel to 2.6.33 and try the patches
> attached to that bug report?
>
> Reinette
>
>
>

Re: Re:

[reinette chatre]

On Fri, 2010-03-19 at 09:49 -0700, Vasil Lalov wrote:
> Thanks for responding to this. I also noticed other things. It seems
> that this Microcode SW error occurs because the wifi card is
> overheating. When used in n-mode and there is a large file transfer,
> the temperature of the card rises to over 62C. Soon after this, the
> microcode error occurs and the card gets disassociated.
> 
> Doing more research on the power vs temperature problem, I discovered
> that other users are seeing this as well. Some have solved their
> problem by enabling the power management for the wifi card by issuing

I am not familiar with these workarounds. Could you please submit a new
bug at http://bugzilla.intellinuxwireless.org/ or add your information
to a bug in this system if you find one that is related? 

Reinette

Re: Re:

[Vasil Lalov]

Reinette,

Thanks a lot for directing me to the right place. I will open up a new
bugreport right away!
Have a good weekend!

Vasil
===
Vasil Lalov
Sr. Systems Administrator
Chicago Public Library


On Fri, Mar 19, 2010 at 12:10 PM, reinette chatre
<reinette.chatre@intel.com> wrote:
> On Fri, 2010-03-19 at 09:49 -0700, Vasil Lalov wrote:
>> Thanks for responding to this. I also noticed other things. It seems
>> that this Microcode SW error occurs because the wifi card is
>> overheating. When used in n-mode and there is a large file transfer,
>> the temperature of the card rises to over 62C. Soon after this, the
>> microcode error occurs and the card gets disassociated.
>>
>> Doing more research on the power vs temperature problem, I discovered
>> that other users are seeing this as well. Some have solved their
>> problem by enabling the power management for the wifi card by issuing
>
> I am not familiar with these workarounds. Could you please submit a new
> bug at http://bugzilla.intellinuxwireless.org/ or add your information
> to a bug in this system if you find one that is related?
>
> Reinette
>
>
>
>

Re:

[Luis R. Rodriguez]

eek sorry, forgot the sha1sum on git format-patch :)

On Mon, May 10, 2010 at 12:22 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re:

[Johannes Berg]

On Sat, 2011-04-30 at 19:30 -0700, Naveen Singh wrote:
> From: Naveen Singh <nsingh@atheros.com>
> 
> The WPA-PSK association was not going through with 2.6.38
> kernel. It was found that supplicant was not able to set
> the PTK key. On further analysis it was found that the function
> nl80211_set_key in file net/wireless/nl80211.c is returning with
> code as -EOPNOTSUPP. This function has been modified to check for
> the flag "WIPHY_FLAG_SUPPORTS_SEPARATE_DEFAULT_KEYS"in wiphy
> struct. If this flag is not set in the driver init, it returns
> from here thereby causing the association to fail. The solution
> is to set this flag in driver init as there would be separate
> default keys for unicast and multicast packets.

We were discussing this before ... and I think the bug is in the
supplicant actually asking for the GTK to be set as the default key or
something like that.

In any case, this doesn't seem right unless you actually do support
separate unicast keys. Are you sure you fully understand what you're
doing here, and not just randomly hacking in a workaround?

johannes

Re:

[Mohammed Shafi]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@gmail.com> wrote:
> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
> some APs on my laptop with an AR9285 Wireless card.
>
> dhcp works fine on an open wifi network but receives no response on a
> wep network I use. I haven't been able to test it on a third network
> for now.

 reverting  "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
helps.  i  need to analyze
if it exposes some real issue which need to be fixed.


> Reverting to 3.2.1 solved the issue which is still there in the latest
> git revision as of today.
>
> DHCPDISCOVER requests are still sent but no ACK is received (nothing
> in Wireshark).
>
> dhcp failure may be one particular instance of the problem but I
> haven't been able to connect with a static ip (my ap doesn't like it)
> so this is the
> only result I know.
>
>
> ver_linux output (latest git kernel) :
>
> Linux litbox 3.3.0-rc1-hack-00383-g0a96265 #1 SMP PREEMPT Mon Jan 30
> 02:22:54 CET 2012 x86_64 Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
> GenuineIntel GNU/Linux
>
> Gnu C                  4.6.2
> Gnu make               3.82
> binutils               2.22.0.20111227
> util-linux             2.20.1
> mount                  support
> module-init-tools      4
> e2fsprogs              1.42
> jfsutils               1.1.15
> reiserfsprogs          3.6.21
> xfsprogs               3.1.7
> pcmciautils            018
> PPP                    2.4.5
> Linux C Library        2.15
> Dynamic linker (ldd)   2.15
> Linux C++ Library      so.6.0
> Procps                 3.2.8
> Net-tools              1.60
> Kbd                    1.15.3
> Sh-utils               8.15
> wireless-tools         29
> Modules Loaded         ipv6 cpufreq_ondemand fuse xts gf128mul
> uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev
> v4l2_compat_ioctl32 media arc4 ath9k ath9k_common ath9k_hw nouveau
> ehci_hcd usbcore i915 snd_hda_codec_hdmi snd_hda_codec_realtek joydev
> ath ttm intel_ips mac80211 cfg80211 asus_laptop sparse_keymap rfkill
> drm_kms_helper drm snd_hda_intel snd_hda_codec snd_hwdep mxm_wmi
> psmouse i2c_algo_bit serio_raw i2c_core pcspkr input_polldev mei
> iTCO_wdt usb_common evdev intel_agp iTCO_vendor_support intel_gtt
> atl1c wmi video snd_pcm snd_page_alloc snd_timer snd soundcore thermal
> battery ac button tun kvm_intel kvm aes_x86_64 aes_generic
> acpi_cpufreq mperf processor freq_table ext4 crc16 jbd2 mbcache
> dm_crypt dm_mod sd_mod ahci libahci libata scsi_mod
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
shafi

[-- Attachment #2: 0001-Revert-ath9k_hw-fix-interpretation-of-the-rx-KeyMiss.patch --]
[-- Type: text/x-diff, Size: 1813 bytes --]

From 171ef4d092d47bf63b33b1e4d5eafd4320e6bb1d Mon Sep 17 00:00:00 2001
From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Date: Tue, 31 Jan 2012 10:36:47 +0530
Subject: [PATCH] Revert "ath9k_hw: fix interpretation of the rx KeyMiss flag"

This reverts commit 7a532fe7131216a02c81a6c1b1f8632da1195a58.
---
 drivers/net/wireless/ath/ath9k/ar9003_mac.c |    5 ++---
 drivers/net/wireless/ath/ath9k/mac.c        |    5 ++---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 09b8c9d..88c81c5 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -557,11 +557,10 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
 			rxs->rs_status |= ATH9K_RXERR_DECRYPT;
 		else if (rxsp->status11 & AR_MichaelErr)
 			rxs->rs_status |= ATH9K_RXERR_MIC;
+		if (rxsp->status11 & AR_KeyMiss)
+			rxs->rs_status |= ATH9K_RXERR_KEYMISS;
 	}
 
-	if (rxsp->status11 & AR_KeyMiss)
-		rxs->rs_status |= ATH9K_RXERR_KEYMISS;
-
 	return 0;
 }
 EXPORT_SYMBOL(ath9k_hw_process_rxdesc_edma);
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index e196aba..fd3f19c 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -618,11 +618,10 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
 			rs->rs_status |= ATH9K_RXERR_DECRYPT;
 		else if (ads.ds_rxstatus8 & AR_MichaelErr)
 			rs->rs_status |= ATH9K_RXERR_MIC;
+		if (ads.ds_rxstatus8 & AR_KeyMiss)
+			rs->rs_status |= ATH9K_RXERR_KEYMISS;
 	}
 
-	if (ads.ds_rxstatus8 & AR_KeyMiss)
-		rs->rs_status |= ATH9K_RXERR_KEYMISS;
-
 	return 0;
 }
 EXPORT_SYMBOL(ath9k_hw_rxprocdesc);
-- 
1.7.0.4

Re:

[Mohammed Shafi]

On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@gmail.com> wrote:
>> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>> some APs on my laptop with an AR9285 Wireless card.
>>
>> dhcp works fine on an open wifi network but receives no response on a
>> wep network I use. I haven't been able to test it on a third network
>> for now.
>
>  reverting  "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
> helps.  i  need to analyze
> if it exposes some real issue which need to be fixed.
>

this seems to be a problem in WEP alone, where the key miss is always
set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
decrypt,  but fails due to ICV mismatch.

-- 
shafi

Re:

[John W. Linville]

On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
> <shafi.wireless@gmail.com> wrote:
> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@gmail.com> wrote:
> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
> >> some APs on my laptop with an AR9285 Wireless card.
> >>
> >> dhcp works fine on an open wifi network but receives no response on a
> >> wep network I use. I haven't been able to test it on a third network
> >> for now.
> >
> >  reverting  "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
> > helps.  i  need to analyze
> > if it exposes some real issue which need to be fixed.
> >
> 
> this seems to be a problem in WEP alone, where the key miss is always
> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
> decrypt,  but fails due to ICV mismatch.

OK...any way to differentiate this case at that point in the code?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re:

[Felix Fietkau]

On 2012-02-01 5:27 PM, John W. Linville wrote:
> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>> <shafi.wireless@gmail.com> wrote:
>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@gmail.com> wrote:
>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>> >> some APs on my laptop with an AR9285 Wireless card.
>> >>
>> >> dhcp works fine on an open wifi network but receives no response on a
>> >> wep network I use. I haven't been able to test it on a third network
>> >> for now.
>> >
>> >  reverting  "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>> > helps.  i  need to analyze
>> > if it exposes some real issue which need to be fixed.
>> >
>> 
>> this seems to be a problem in WEP alone, where the key miss is always
>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>> decrypt,  but fails due to ICV mismatch.
> 
> OK...any way to differentiate this case at that point in the code?
> 
> John
Please try this patch:

---
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
 		(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
 		 ATH9K_RXERR_KEYMISS));
 
+	/*
+	 * First 4 slots are reserved for WEP, and for packets using them,
+	 * ATH9K_RXERR_KEYMISS can be reported even though decryption was
+	 * successful, since no MAC address based key cache lookup was
+	 * performed.
+	 */
+	if (rx_stats->rs_keyix < 4)
+		rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
+
 	if (!rx_stats->rs_datalen)
 		return false;
         /*

Re:

[Mohammed Shafi]

Hi Felix,

On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2012-02-01 5:27 PM, John W. Linville wrote:
>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>>> <shafi.wireless@gmail.com> wrote:
>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@gmail.com> wrote:
>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>>> >> some APs on my laptop with an AR9285 Wireless card.
>>> >>
>>> >> dhcp works fine on an open wifi network but receives no response on a
>>> >> wep network I use. I haven't been able to test it on a third network
>>> >> for now.
>>> >
>>> >  reverting  "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>>> > helps.  i  need to analyze
>>> > if it exposes some real issue which need to be fixed.
>>> >
>>>
>>> this seems to be a problem in WEP alone, where the key miss is always
>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>>> decrypt,  but fails due to ICV mismatch.
>>
>> OK...any way to differentiate this case at that point in the code?
>>
>> John
> Please try this patch:
>
> ---
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
>                (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>                 ATH9K_RXERR_KEYMISS));
>
> +       /*
> +        * First 4 slots are reserved for WEP, and for packets using them,
> +        * ATH9K_RXERR_KEYMISS can be reported even though decryption was
> +        * successful, since no MAC address based key cache lookup was
> +        * performed.
> +        */
> +       if (rx_stats->rs_keyix < 4)
> +               rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
> +
>        if (!rx_stats->rs_datalen)
>                return false;
>         /*


unfortunately as the rx_keyix is always 'INVALID' (as obtained from
the descriptor) this check does not seems to help

-- 
shafi

Re:

[Felix Fietkau]

On 2012-02-02 6:37 AM, Mohammed Shafi wrote:
> Hi Felix,
> 
> On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2012-02-01 5:27 PM, John W. Linville wrote:
>>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>>>> <shafi.wireless@gmail.com> wrote:
>>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@gmail.com> wrote:
>>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>>>> >> some APs on my laptop with an AR9285 Wireless card.
>>>> >>
>>>> >> dhcp works fine on an open wifi network but receives no response on a
>>>> >> wep network I use. I haven't been able to test it on a third network
>>>> >> for now.
>>>> >
>>>> >  reverting  "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>>>> > helps.  i  need to analyze
>>>> > if it exposes some real issue which need to be fixed.
>>>> >
>>>>
>>>> this seems to be a problem in WEP alone, where the key miss is always
>>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>>>> decrypt,  but fails due to ICV mismatch.
>>>
>>> OK...any way to differentiate this case at that point in the code?
>>>
>>> John
>> Please try this patch:
>>
>> ---
>> --- a/drivers/net/wireless/ath/ath9k/recv.c
>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
>> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
>>                (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>>                 ATH9K_RXERR_KEYMISS));
>>
>> +       /*
>> +        * First 4 slots are reserved for WEP, and for packets using them,
>> +        * ATH9K_RXERR_KEYMISS can be reported even though decryption was
>> +        * successful, since no MAC address based key cache lookup was
>> +        * performed.
>> +        */
>> +       if (rx_stats->rs_keyix < 4)
>> +               rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
>> +
>>        if (!rx_stats->rs_datalen)
>>                return false;
>>         /*
> 
> 
> unfortunately as the rx_keyix is always 'INVALID' (as obtained from
> the descriptor) this check does not seems to help
You're right. I read up on what the other codebases do here, and I have
a better patch here:

--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -823,6 +823,14 @@ static bool ath9k_rx_accept(struct ath_c
 		(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
 		 ATH9K_RXERR_KEYMISS));
 
+	/*
+	 * Key miss events are only relevant for pairwise keys where the
+	 * descriptor does contain a valid key index. This has been observed
+	 * mostly with CCMP encryption.
+	 */
+	if (rx_stats->rs_keyix == ATH9K_RXKEYIX_INVALID)
+		rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
+
 	if (!rx_stats->rs_datalen)
 		return false;
         /*

Re:

[Mohammed Shafi]

On Thu, Feb 2, 2012 at 5:58 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2012-02-02 6:37 AM, Mohammed Shafi wrote:
>> Hi Felix,
>>
>> On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> On 2012-02-01 5:27 PM, John W. Linville wrote:
>>>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>>>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>>>>> <shafi.wireless@gmail.com> wrote:
>>>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@gmail.com> wrote:
>>>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>>>>> >> some APs on my laptop with an AR9285 Wireless card.
>>>>> >>
>>>>> >> dhcp works fine on an open wifi network but receives no response on a
>>>>> >> wep network I use. I haven't been able to test it on a third network
>>>>> >> for now.
>>>>> >
>>>>> >  reverting  "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>>>>> > helps.  i  need to analyze
>>>>> > if it exposes some real issue which need to be fixed.
>>>>> >
>>>>>
>>>>> this seems to be a problem in WEP alone, where the key miss is always
>>>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>>>>> decrypt,  but fails due to ICV mismatch.
>>>>
>>>> OK...any way to differentiate this case at that point in the code?
>>>>
>>>> John
>>> Please try this patch:
>>>
>>> ---
>>> --- a/drivers/net/wireless/ath/ath9k/recv.c
>>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
>>> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
>>>                (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>>>                 ATH9K_RXERR_KEYMISS));
>>>
>>> +       /*
>>> +        * First 4 slots are reserved for WEP, and for packets using them,
>>> +        * ATH9K_RXERR_KEYMISS can be reported even though decryption was
>>> +        * successful, since no MAC address based key cache lookup was
>>> +        * performed.
>>> +        */
>>> +       if (rx_stats->rs_keyix < 4)
>>> +               rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
>>> +
>>>        if (!rx_stats->rs_datalen)
>>>                return false;
>>>         /*
>>
>>
>> unfortunately as the rx_keyix is always 'INVALID' (as obtained from
>> the descriptor) this check does not seems to help
> You're right. I read up on what the other codebases do here, and I have
> a better patch here:
>
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -823,6 +823,14 @@ static bool ath9k_rx_accept(struct ath_c
>                (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>                 ATH9K_RXERR_KEYMISS));
>
> +       /*
> +        * Key miss events are only relevant for pairwise keys where the
> +        * descriptor does contain a valid key index. This has been observed
> +        * mostly with CCMP encryption.
> +        */
> +       if (rx_stats->rs_keyix == ATH9K_RXKEYIX_INVALID)
> +               rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
> +
>        if (!rx_stats->rs_datalen)
>                return false;
>         /*
>

this works for me (WEP key configured).

-- 
shafi

Re:

[Laurent Bonnans]

It works for me too.

On Thu, Feb 2, 2012 at 1:28 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2012-02-02 6:37 AM, Mohammed Shafi wrote:
>> Hi Felix,
>>
>> On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> On 2012-02-01 5:27 PM, John W. Linville wrote:
>>>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>>>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>>>>> <shafi.wireless@gmail.com> wrote:
>>>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <bonnans.l@gmail.com> wrote:
>>>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>>>>> >> some APs on my laptop with an AR9285 Wireless card.
>>>>> >>
>>>>> >> dhcp works fine on an open wifi network but receives no response on a
>>>>> >> wep network I use. I haven't been able to test it on a third network
>>>>> >> for now.
>>>>> >
>>>>> >  reverting  "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>>>>> > helps.  i  need to analyze
>>>>> > if it exposes some real issue which need to be fixed.
>>>>> >
>>>>>
>>>>> this seems to be a problem in WEP alone, where the key miss is always
>>>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>>>>> decrypt,  but fails due to ICV mismatch.
>>>>
>>>> OK...any way to differentiate this case at that point in the code?
>>>>
>>>> John
>>> Please try this patch:
>>>
>>> ---
>>> --- a/drivers/net/wireless/ath/ath9k/recv.c
>>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
>>> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
>>>                (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>>>                 ATH9K_RXERR_KEYMISS));
>>>
>>> +       /*
>>> +        * First 4 slots are reserved for WEP, and for packets using them,
>>> +        * ATH9K_RXERR_KEYMISS can be reported even though decryption was
>>> +        * successful, since no MAC address based key cache lookup was
>>> +        * performed.
>>> +        */
>>> +       if (rx_stats->rs_keyix < 4)
>>> +               rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
>>> +
>>>        if (!rx_stats->rs_datalen)
>>>                return false;
>>>         /*
>>
>>
>> unfortunately as the rx_keyix is always 'INVALID' (as obtained from
>> the descriptor) this check does not seems to help
> You're right. I read up on what the other codebases do here, and I have
> a better patch here:
>
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -823,6 +823,14 @@ static bool ath9k_rx_accept(struct ath_c
>                (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>                 ATH9K_RXERR_KEYMISS));
>
> +       /*
> +        * Key miss events are only relevant for pairwise keys where the
> +        * descriptor does contain a valid key index. This has been observed
> +        * mostly with CCMP encryption.
> +        */
> +       if (rx_stats->rs_keyix == ATH9K_RXKEYIX_INVALID)
> +               rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
> +
>        if (!rx_stats->rs_datalen)
>                return false;
>         /*
>

Re:

[Larry Finger]

On 02/22/2012 12:50 AM, Vlatka Petričec wrote:
> Hi,
> I have linux evolution  and I had a normal wireless connection until
> something changed in maybe network settings and it just stopped
> working. for example it says that my network is active but I cannot
> open any web adress or is just active but every function on computer
> says it is not active. I am thanking you in advance thank you for your
> time.

Vlatka,

I have some suggestions for you.

First, never submit an E-mail to anyone, and especially to a mailing list 
without a subject that is a good description of your problem. Most experts will 
have their mail filters set up to direct a subject-less message directly to the 
spam bucket. I think I need to do that too.

Second, you give no information that would let anyone help you. "It just stopped 
working" does no good. Knowing what changed is critical. If the kernel changed 
when it stopped, then this list might be the right place to ask. If something 
was updated by the distro, then get your help there as very few of us would know 
how evolution works. if nothing changed, then your settings just got corrupted, 
and you definitely need to contact the support at evolution.

If you think that it is a kernel or driver problem, then you absolutely must 
state what hardware you have, what driver it uses, and the PCI or USB ID that 
describes it. You also need to state what kernel works, and what version fails.

Larry

Re:

[Johannes Berg]

On Mon, 2013-02-11 at 13:38 +0100, Johannes Berg wrote:
> These patches improve/fix HT handling, particularly the bandwidth
> change handling that we were missing entirely and HT capability
> handling (which touches many drivers, unfortunately.)
> 
> This should make the VHT handling compliant with D4.0, I hope.

I did a little bit more testing and applied all.

johannes

Re:

[Rafał Miłecki]

2013/4/12 Callum Hutchinson <callumhutchinson1@gmail.com>:
> Tried to report this properly via email but got some formatting issues
> coming back, I've attached the content of the original email report as
> 'Report.txt'.
>
> It is the same file as found on comment 12 on Launchpad bug.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1142385
>
> Apologies for any missing information or lack of reporting experience :)

Sending e-mail with empty subject and without direct information about
the hardware isn't a good idea.

It's most probably another result of regression I've tracked and reported in:
Scanning regression since "cfg80211: use DS or HT operation IEs to
determine BSS channel"

http://www.spinics.net/lists/linux-wireless/msg105359.html
http://marc.info/?t=136431795000003&r=1&w=4

I didn't have enough time to debug it further and fix yet.

-- 
Rafał

Re:

[Joe Perches]

On Mon, 2013-07-08 at 21:52 +0000, Jeffrey (Sheng-Hui) Chu wrote:
[]
> diff --git a/drivers/nfc/bcm2079x/bcm2079x-i2c.c b/drivers/nfc/bcm2079x/bcm2079x-i2c.c
[]
> +/* do not change below */
> +#define MAX_BUFFER_SIZE		780
[]
> +static ssize_t bcm2079x_dev_read(struct file *filp, char __user *buf,
> +					size_t count, loff_t *offset)
> +{
> +	struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> +	unsigned char tmp[MAX_BUFFER_SIZE];

780 bytes on stack isn't a great idea.

> +static ssize_t bcm2079x_dev_write(struct file *filp, const char __user *buf,
> +					size_t count, loff_t *offset)
> +{
> +	struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> +	char tmp[MAX_BUFFER_SIZE];

etc.

> +	int ret;
> +
> +	if (count > MAX_BUFFER_SIZE) {
> +		dev_err(&bcm2079x_dev->client->dev, "out of memory\n");

Out of memory isn't really true.
The packet size is just too big for your
little buffer.

> +static int bcm2079x_dev_open(struct inode *inode, struct file *filp)
> +{
> +	int ret = 0;
> +
> +	struct bcm2079x_dev *bcm2079x_dev = container_of(filp->private_data,
> +							struct bcm2079x_dev,
> +							bcm2079x_device);
> +	filp->private_data = bcm2079x_dev;
> +	bcm2079x_init_stat(bcm2079x_dev);
> +	bcm2079x_enable_irq(bcm2079x_dev);
> +	dev_info(&bcm2079x_dev->client->dev,
> +		 "%d,%d\n", imajor(inode), iminor(inode));

Looks to me like this should be dev_dbg not dev_info

Re:

[Arend van Spriel]

+ Samuel

On 07/08/2013 11:52 PM, Jeffrey (Sheng-Hui) Chu wrote:
>  From b4555081b1d27a31c22abede8e0397f1d61fbb04 Mon Sep 17 00:00:00 2001
> From: Jeffrey Chu <jeffchu@broadcom.com>
> Date: Mon, 8 Jul 2013 17:50:21 -0400
> Subject: [PATCH] Add bcm2079x-i2c driver for Bcm2079x NFC Controller.

The subject did not show in my mailbox. Not sure if necessary, but I 
tend to send patches to a maintainer and CC the appropriate list(s). So 
the nfc list as well (linux-nfc@lists.01.org).

Regards,
Arend

> Signed-off-by: Jeffrey Chu <jeffchu@broadcom.com>
> ---
>   drivers/nfc/Kconfig                 |    1 +
>   drivers/nfc/Makefile                |    1 +
>   drivers/nfc/bcm2079x/Kconfig        |   10 +
>   drivers/nfc/bcm2079x/Makefile       |    4 +
>   drivers/nfc/bcm2079x/bcm2079x-i2c.c |  416 +++++++++++++++++++++++++++++++++++
>   drivers/nfc/bcm2079x/bcm2079x.h     |   34 +++
>   6 files changed, 466 insertions(+)
>   create mode 100644 drivers/nfc/bcm2079x/Kconfig
>   create mode 100644 drivers/nfc/bcm2079x/Makefile
>   create mode 100644 drivers/nfc/bcm2079x/bcm2079x-i2c.c
>   create mode 100644 drivers/nfc/bcm2079x/bcm2079x.h
>
> diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
> index 74a852e..fa540f4 100644
> --- a/drivers/nfc/Kconfig
> +++ b/drivers/nfc/Kconfig
> @@ -38,5 +38,6 @@ config NFC_MEI_PHY
>
>   source "drivers/nfc/pn544/Kconfig"
>   source "drivers/nfc/microread/Kconfig"
> +source "drivers/nfc/bcm2079x/Kconfig"
>
>   endmenu
> diff --git a/drivers/nfc/Makefile b/drivers/nfc/Makefile
> index aa6bd65..a56adf6 100644
> --- a/drivers/nfc/Makefile
> +++ b/drivers/nfc/Makefile
> @@ -7,5 +7,6 @@ obj-$(CONFIG_NFC_MICROREAD)	+= microread/
>   obj-$(CONFIG_NFC_PN533)		+= pn533.o
>   obj-$(CONFIG_NFC_WILINK)	+= nfcwilink.o
>   obj-$(CONFIG_NFC_MEI_PHY)	+= mei_phy.o
> +obj-$(CONFIG_NFC_PN544)		+= bcm2079x/

I suspect this is a copy-paste error right? Should be 
obj-$(CONFIG_NFC_BCM2079X_I2C).

>
>   ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG
> diff --git a/drivers/nfc/bcm2079x/Kconfig b/drivers/nfc/bcm2079x/Kconfig
> new file mode 100644
> index 0000000..889e181
> --- /dev/null
> +++ b/drivers/nfc/bcm2079x/Kconfig
> @@ -0,0 +1,10 @@
> +config NFC_BCM2079X_I2C
> +	tristate "NFC BCM2079x i2c support"
> +	depends on I2C
> +	default n
> +	---help---
> +	  Broadcom BCM2079x i2c driver.
> +	  This is a driver that allows transporting NCI/HCI command and response
> +	  to/from Broadcom bcm2079x NFC Controller.  Select this if your
> +	  platform is using i2c bus to controll this chip.
> +
> diff --git a/drivers/nfc/bcm2079x/Makefile b/drivers/nfc/bcm2079x/Makefile
> new file mode 100644
> index 0000000..be64d35
> --- /dev/null
> +++ b/drivers/nfc/bcm2079x/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# Makefile for bcm2079x NFC driver
> +#
> +obj-$(CONFIG_NFC_BCM2079X_I2C) += bcm2079x-i2c.o
> diff --git a/drivers/nfc/bcm2079x/bcm2079x-i2c.c b/drivers/nfc/bcm2079x/bcm2079x-i2c.c
> new file mode 100644
> index 0000000..988a65e
> --- /dev/null
> +++ b/drivers/nfc/bcm2079x/bcm2079x-i2c.c
> @@ -0,0 +1,416 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/fs.h>
> +#include <linux/slab.h>
> +#include <linux/i2c.h>
> +#include <linux/irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/gpio.h>
> +#include <linux/miscdevice.h>
> +#include <linux/spinlock.h>
> +#include <linux/poll.h>
> +
> +#include "bcm2079x.h"
> +
> +/* do not change below */
> +#define MAX_BUFFER_SIZE		780
> +
> +/* Read data */
> +#define PACKET_HEADER_SIZE_NCI	(4)
> +#define PACKET_HEADER_SIZE_HCI	(3)
> +#define PACKET_TYPE_NCI		(16)
> +#define PACKET_TYPE_HCIEV	(4)
> +#define MAX_PACKET_SIZE		(PACKET_HEADER_SIZE_NCI + 255)
> +
> +struct bcm2079x_dev {
> +	wait_queue_head_t read_wq;
> +	struct mutex read_mutex;
> +	struct i2c_client *client;
> +	struct miscdevice bcm2079x_device;
> +	unsigned int wake_gpio;
> +	unsigned int en_gpio;
> +	unsigned int irq_gpio;
> +	bool irq_enabled;
> +	spinlock_t irq_enabled_lock;
> +	unsigned int count_irq;
> +};
> +
> +static void bcm2079x_init_stat(struct bcm2079x_dev *bcm2079x_dev)
> +{
> +	bcm2079x_dev->count_irq = 0;
> +}
> +
> +static void bcm2079x_disable_irq(struct bcm2079x_dev *bcm2079x_dev)
> +{
> +	unsigned long flags;
> +	spin_lock_irqsave(&bcm2079x_dev->irq_enabled_lock, flags);
> +	if (bcm2079x_dev->irq_enabled) {
> +		disable_irq_nosync(bcm2079x_dev->client->irq);
> +		bcm2079x_dev->irq_enabled = false;
> +	}
> +	spin_unlock_irqrestore(&bcm2079x_dev->irq_enabled_lock, flags);
> +}
> +
> +static void bcm2079x_enable_irq(struct bcm2079x_dev *bcm2079x_dev)
> +{
> +	unsigned long flags;
> +	spin_lock_irqsave(&bcm2079x_dev->irq_enabled_lock, flags);
> +	if (!bcm2079x_dev->irq_enabled) {
> +		bcm2079x_dev->irq_enabled = true;
> +		enable_irq(bcm2079x_dev->client->irq);
> +	}
> +	spin_unlock_irqrestore(&bcm2079x_dev->irq_enabled_lock, flags);
> +}
> +
> +static void set_client_addr(struct bcm2079x_dev *bcm2079x_dev, int addr)
> +{
> +	struct i2c_client *client = bcm2079x_dev->client;
> +	dev_info(&client->dev,
> +		"Set client device address from 0x%04X flag = "
> +		"%02x, to  0x%04X\n",
> +		client->addr, client->flags, addr);
> +		client->addr = addr;
> +		if (addr < 0x80)
> +			client->flags &= ~I2C_CLIENT_TEN;
> +		else
> +			client->flags |= I2C_CLIENT_TEN;
> +}
> +
> +static irqreturn_t bcm2079x_dev_irq_handler(int irq, void *dev_id)
> +{
> +	struct bcm2079x_dev *bcm2079x_dev = dev_id;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&bcm2079x_dev->irq_enabled_lock, flags);
> +	bcm2079x_dev->count_irq++;
> +	spin_unlock_irqrestore(&bcm2079x_dev->irq_enabled_lock, flags);
> +	wake_up(&bcm2079x_dev->read_wq);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static unsigned int bcm2079x_dev_poll(struct file *filp, poll_table *wait)
> +{
> +	struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> +	unsigned int mask = 0;
> +	unsigned long flags;
> +
> +	poll_wait(filp, &bcm2079x_dev->read_wq, wait);
> +
> +	spin_lock_irqsave(&bcm2079x_dev->irq_enabled_lock, flags);
> +	if (bcm2079x_dev->count_irq > 0) {
> +		bcm2079x_dev->count_irq--;
> +		mask |= POLLIN | POLLRDNORM;
> +	}
> +	spin_unlock_irqrestore(&bcm2079x_dev->irq_enabled_lock, flags);
> +
> +	return mask;
> +}
> +
> +static ssize_t bcm2079x_dev_read(struct file *filp, char __user *buf,
> +					size_t count, loff_t *offset)
> +{
> +	struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> +	unsigned char tmp[MAX_BUFFER_SIZE];
> +	int total, len, ret;
> +
> +	total = 0;
> +	len = 0;
> +
> +	if (count > MAX_BUFFER_SIZE)
> +		count = MAX_BUFFER_SIZE;
> +
> +	mutex_lock(&bcm2079x_dev->read_mutex);
> +
> +	/* Read the first 4 bytes to include the length of the NCI or
> +		HCI packet.*/
> +	ret = i2c_master_recv(bcm2079x_dev->client, tmp, 4);
> +	if (ret == 4) {
> +		total = ret;
> +		/* First byte is the packet type*/
> +		switch (tmp[0]) {
> +		case PACKET_TYPE_NCI:
> +			len = tmp[PACKET_HEADER_SIZE_NCI-1];
> +			break;
> +
> +		case PACKET_TYPE_HCIEV:
> +			len = tmp[PACKET_HEADER_SIZE_HCI-1];
> +			if (len == 0)
> +				total--;
> +			else
> +				len--;
> +			break;
> +
> +		default:
> +			len = 0;/*Unknown packet byte */
> +			break;
> +		} /* switch*/
> +
> +		/* make sure full packet fits in the buffer*/
> +		if (len > 0 && (len + total) <= count) {
> +			/** read the remainder of the packet.
> +			**/
> +			ret = i2c_master_recv(bcm2079x_dev->client, tmp+total,
> +				len);
> +			if (ret == len)
> +				total += len;
> +		} /* if */
> +	} /* if */
> +
> +	mutex_unlock(&bcm2079x_dev->read_mutex);
> +
> +	if (total > count || copy_to_user(buf, tmp, total)) {
> +		dev_err(&bcm2079x_dev->client->dev,
> +			"failed to copy to user space, total = %d\n", total);
> +		total = -EFAULT;
> +	}
> +
> +	return total;
> +}
> +
> +static ssize_t bcm2079x_dev_write(struct file *filp, const char __user *buf,
> +					size_t count, loff_t *offset)
> +{
> +	struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> +	char tmp[MAX_BUFFER_SIZE];
> +	int ret;
> +
> +	if (count > MAX_BUFFER_SIZE) {
> +		dev_err(&bcm2079x_dev->client->dev, "out of memory\n");
> +		return -ENOMEM;
> +	}
> +
> +	if (copy_from_user(tmp, buf, count)) {
> +		dev_err(&bcm2079x_dev->client->dev,
> +			"failed to copy from user space\n");
> +		return -EFAULT;
> +	}
> +
> +	mutex_lock(&bcm2079x_dev->read_mutex);
> +	/* Write data */
> +
> +	ret = i2c_master_send(bcm2079x_dev->client, tmp, count);
> +	if (ret != count) {
> +		dev_err(&bcm2079x_dev->client->dev,
> +			"failed to write %d\n", ret);
> +		ret = -EIO;
> +	}
> +	mutex_unlock(&bcm2079x_dev->read_mutex);
> +
> +	return ret;
> +}
> +
> +static int bcm2079x_dev_open(struct inode *inode, struct file *filp)
> +{
> +	int ret = 0;
> +
> +	struct bcm2079x_dev *bcm2079x_dev = container_of(filp->private_data,
> +							struct bcm2079x_dev,
> +							bcm2079x_device);
> +	filp->private_data = bcm2079x_dev;
> +	bcm2079x_init_stat(bcm2079x_dev);
> +	bcm2079x_enable_irq(bcm2079x_dev);
> +	dev_info(&bcm2079x_dev->client->dev,
> +		 "%d,%d\n", imajor(inode), iminor(inode));
> +
> +	return ret;
> +}
> +
> +static long bcm2079x_dev_unlocked_ioctl(struct file *filp,
> +					 unsigned int cmd, unsigned long arg)
> +{
> +	struct bcm2079x_dev *bcm2079x_dev = filp->private_data;
> +
> +	switch (cmd) {
> +	case BCMNFC_POWER_CTL:
> +		gpio_set_value(bcm2079x_dev->en_gpio, arg);
> +		break;
> +	case BCMNFC_WAKE_CTL:
> +		gpio_set_value(bcm2079x_dev->wake_gpio, arg);
> +		break;
> +	case BCMNFC_SET_ADDR:
> +		set_client_addr(bcm2079x_dev, arg);
> +		break;
> +	default:
> +		dev_err(&bcm2079x_dev->client->dev,
> +			"%s, unknown cmd (%x, %lx)\n", __func__, cmd, arg);
> +		return -ENOSYS;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct file_operations bcm2079x_dev_fops = {
> +	.owner = THIS_MODULE,
> +	.llseek = no_llseek,
> +	.poll = bcm2079x_dev_poll,
> +	.read = bcm2079x_dev_read,
> +	.write = bcm2079x_dev_write,
> +	.open = bcm2079x_dev_open,
> +	.unlocked_ioctl = bcm2079x_dev_unlocked_ioctl
> +};
> +
> +static int bcm2079x_probe(struct i2c_client *client,
> +				const struct i2c_device_id *id)
> +{
> +	int ret;
> +	struct bcm2079x_platform_data *platform_data;
> +	struct bcm2079x_dev *bcm2079x_dev;
> +
> +	platform_data = client->dev.platform_data;
> +
> +	dev_info(&client->dev, "%s, probing bcm2079x driver flags = %x\n",
> +		__func__, client->flags);
> +	if (platform_data == NULL) {
> +		dev_err(&client->dev, "nfc probe fail\n");
> +		return -ENODEV;
> +	}
> +
> +	if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> +		dev_err(&client->dev, "need I2C_FUNC_I2C\n");
> +		return -ENODEV;
> +	}
> +
> +	ret = gpio_request_one(platform_data->irq_gpio, GPIOF_IN, "nfc_irq");
> +	if (ret)
> +		return -ENODEV;
> +	ret = gpio_request_one(platform_data->en_gpio, GPIOF_OUT_INIT_LOW,
> +		"nfc_en");
> +	if (ret)
> +		goto err_en;
> +	ret = gpio_request_one(platform_data->wake_gpio, GPIOF_OUT_INIT_LOW,
> +		"nfc_wake");
> +	if (ret)
> +		goto err_wake;
> +
> +	gpio_set_value(platform_data->en_gpio, 0);
> +	gpio_set_value(platform_data->wake_gpio, 0);
> +
> +	bcm2079x_dev = kzalloc(sizeof(*bcm2079x_dev), GFP_KERNEL);
> +	if (bcm2079x_dev == NULL) {
> +		dev_err(&client->dev,
> +			"failed to allocate memory for module data\n");
> +		ret = -ENOMEM;
> +		goto err_exit;
> +	}
> +
> +	bcm2079x_dev->wake_gpio = platform_data->wake_gpio;
> +	bcm2079x_dev->irq_gpio = platform_data->irq_gpio;
> +	bcm2079x_dev->en_gpio = platform_data->en_gpio;
> +	bcm2079x_dev->client = client;
> +
> +	/* init mutex and queues */
> +	init_waitqueue_head(&bcm2079x_dev->read_wq);
> +	mutex_init(&bcm2079x_dev->read_mutex);
> +	spin_lock_init(&bcm2079x_dev->irq_enabled_lock);
> +
> +	bcm2079x_dev->bcm2079x_device.minor = MISC_DYNAMIC_MINOR;
> +	bcm2079x_dev->bcm2079x_device.name = "bcm2079x-i2c";
> +	bcm2079x_dev->bcm2079x_device.fops = &bcm2079x_dev_fops;
> +
> +	ret = misc_register(&bcm2079x_dev->bcm2079x_device);
> +	if (ret) {
> +		dev_err(&client->dev, "misc_register failed\n");
> +		goto err_misc_register;
> +	}
> +
> +	/* request irq.  the irq is set whenever the chip has data available
> +	 * for reading.  it is cleared when all data has been read.
> +	 */
> +	dev_info(&client->dev, "requesting IRQ %d\n", client->irq);
> +	bcm2079x_dev->irq_enabled = true;
> +	ret = request_irq(client->irq, bcm2079x_dev_irq_handler,
> +			IRQF_TRIGGER_RISING, client->name, bcm2079x_dev);
> +	if (ret) {
> +		dev_err(&client->dev, "request_irq failed\n");
> +		goto err_request_irq_failed;
> +	}
> +	bcm2079x_disable_irq(bcm2079x_dev);
> +	i2c_set_clientdata(client, bcm2079x_dev);
> +	dev_info(&client->dev,
> +		 "%s, probing bcm2079x driver exited successfully\n",
> +		 __func__);
> +	return 0;
> +
> +err_request_irq_failed:
> +	misc_deregister(&bcm2079x_dev->bcm2079x_device);
> +err_misc_register:
> +	mutex_destroy(&bcm2079x_dev->read_mutex);
> +	kfree(bcm2079x_dev);
> +err_exit:
> +	gpio_free(platform_data->wake_gpio);
> +err_wake:
> +	gpio_free(platform_data->en_gpio);
> +err_en:
> +	gpio_free(platform_data->irq_gpio);
> +	return ret;
> +}
> +
> +static int bcm2079x_remove(struct i2c_client *client)
> +{
> +	struct bcm2079x_dev *bcm2079x_dev;
> +
> +	bcm2079x_dev = i2c_get_clientdata(client);
> +	free_irq(client->irq, bcm2079x_dev);
> +	misc_deregister(&bcm2079x_dev->bcm2079x_device);
> +	mutex_destroy(&bcm2079x_dev->read_mutex);
> +	gpio_free(bcm2079x_dev->irq_gpio);
> +	gpio_free(bcm2079x_dev->en_gpio);
> +	gpio_free(bcm2079x_dev->wake_gpio);
> +	kfree(bcm2079x_dev);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id bcm2079x_id[] = {
> +	{"bcm2079x-i2c", 0},
> +	{}
> +};
> +
> +static struct i2c_driver bcm2079x_driver = {
> +	.id_table = bcm2079x_id,
> +	.probe = bcm2079x_probe,
> +	.remove = bcm2079x_remove,
> +	.driver = {
> +		.owner = THIS_MODULE,
> +		.name = "bcm2079x-i2c",
> +	},
> +};
> +
> +/*
> + * module load/unload record keeping
> + */
> +
> +static int __init bcm2079x_dev_init(void)
> +{
> +	return i2c_add_driver(&bcm2079x_driver);
> +}
> +module_init(bcm2079x_dev_init);
> +
> +static void __exit bcm2079x_dev_exit(void)
> +{
> +	i2c_del_driver(&bcm2079x_driver);
> +}
> +module_exit(bcm2079x_dev_exit);
> +
> +MODULE_AUTHOR("Broadcom");
> +MODULE_DESCRIPTION("NFC bcm2079x driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/nfc/bcm2079x/bcm2079x.h b/drivers/nfc/bcm2079x/bcm2079x.h
> new file mode 100644
> index 0000000..b8b243f
> --- /dev/null
> +++ b/drivers/nfc/bcm2079x/bcm2079x.h
> @@ -0,0 +1,34 @@
> +/*
> + * Copyright (C) 2013 Broadcom Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +#ifndef _BCM2079X_H
> +#define _BCM2079X_H
> +
> +#define BCMNFC_MAGIC	0xFA
> +
> +#define BCMNFC_POWER_CTL	_IO(BCMNFC_MAGIC, 0x01)
> +#define BCMNFC_WAKE_CTL	_IO(BCMNFC_MAGIC, 0x05)
> +#define BCMNFC_SET_ADDR	_IO(BCMNFC_MAGIC, 0x07)
> +
> +struct bcm2079x_platform_data {
> +	unsigned int irq_gpio;
> +	unsigned int en_gpio;
> +	unsigned int wake_gpio;
> +};
> +
> +#endif
>

Re:

[Samuel Ortiz]

Hi Arend, Jeffrey,

On Tue, Jul 09, 2013 at 03:22:25PM +0200, Arend van Spriel wrote:
> + Samuel
> 
> On 07/08/2013 11:52 PM, Jeffrey (Sheng-Hui) Chu wrote:
> > From b4555081b1d27a31c22abede8e0397f1d61fbb04 Mon Sep 17 00:00:00 2001
> >From: Jeffrey Chu <jeffchu@broadcom.com>
> >Date: Mon, 8 Jul 2013 17:50:21 -0400
> >Subject: [PATCH] Add bcm2079x-i2c driver for Bcm2079x NFC Controller.
> 
> The subject did not show in my mailbox. Not sure if necessary, but I
> tend to send patches to a maintainer and CC the appropriate list(s).
> So the nfc list as well (linux-nfc@lists.01.org).
Thanks for cc'ing me. Yes, the NFC maintainers emails and the mailing
list are in the MAINTAINERS file, so I expect people to use them to post
their NFC related patches.


> >---
> >  drivers/nfc/Kconfig                 |    1 +
> >  drivers/nfc/Makefile                |    1 +
> >  drivers/nfc/bcm2079x/Kconfig        |   10 +
> >  drivers/nfc/bcm2079x/Makefile       |    4 +
> >  drivers/nfc/bcm2079x/bcm2079x-i2c.c |  416 +++++++++++++++++++++++++++++++++++
> >  drivers/nfc/bcm2079x/bcm2079x.h     |   34 +++
> >  6 files changed, 466 insertions(+)
> >  create mode 100644 drivers/nfc/bcm2079x/Kconfig
> >  create mode 100644 drivers/nfc/bcm2079x/Makefile
> >  create mode 100644 drivers/nfc/bcm2079x/bcm2079x-i2c.c
> >  create mode 100644 drivers/nfc/bcm2079x/bcm2079x.h
Jeffrey, I appreciate the upstreaming effort, but I'm not going to take
this patch. It's designed for Android exclusively and not using any of
the NFC kernel APIs.
In particular, we have a full NCI stack that you could use. There
currently is an SPI transport layer, adding an i2c one would be really
easy.
If you're interested and can spend some cycles on this, I can surely
help you with the kernel APIs and how your driver should look like.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re:

[Tomas Pospisek]

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

Re:

[Sedat Dilek]

On Wed, Aug 28, 2013 at 1:07 PM, Marc Murphy <marcmltd@marcm.co.uk> wrote:
> Hello,
> I have been trawling the mailings and lots of people are asking about 802.11p and I have not managed to find a definitive push back to the mainline kernel.
>

Hi,

first of all, you should set a "subject" to your email request :-).

I cannot say much about 802.11p, but for first informations I
recommend the wiki at <http://wireless.kernel.org> and have a look
into docs section.

For faster replies you can join #linux-wireless IRC channel (Freenode).

- Sedat -

> Is there anywhere in particular that I need to be looking to be able to get the patches so I can have a play ?
>
> Thanks
> Marc--
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Sam Leffler]

unsubscribe linux-wireless

Re:

[Oleg Kostyuchenko]

Hi Arend,
I am still experiencing the issue Sebastien initially described (no wlan0 device,
"SDIO drive strength" warnings etc) on a Thinkpad Tablet 10 for the latest
kernel release, 4.2. Doesn't the 4.2 kernel include the required fix?

Thanks,
Oleg

Re:

[Rajat Jain]

Please ignore, not sure why this landed without a subject.

On Tue, Sep 27, 2016 at 9:50 AM, Rajat Jain <rajatja@google.com> wrote:
> From: Wei-Ning Huang <wnhuang@google.com>
>
> Date: Thu, 17 Mar 2016 11:43:16 +0800
> Subject: [PATCH] mwifiex: report wakeup for wowlan
>
> Enable notifying wakeup source to the PM core. This allow darkresume to
> correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
> source.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
> ---
>  drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
>  drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
>  2 files changed, 9 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index d3e1561..a5f63e4 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
>                 disable_irq_nosync(irq);
>         }
>
> +       /* Notify PM core we are wakeup source */
> +       pm_wakeup_event(cfg->dev, 0);
> +
>         return IRQ_HANDLED;
>  }
>
> @@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
>                                           GFP_KERNEL);
>         cfg = card->plt_wake_cfg;
>         if (cfg && card->plt_of_node) {
> +               cfg->dev = dev;
>                 cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
>                 if (!cfg->irq_wifi) {
>                         dev_dbg(dev,
> @@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
>                 }
>         }
>
> +       ret = device_init_wakeup(dev, true);
> +       if (ret)
> +               dev_err(dev, "fail to init wakeup for mwifiex");
> +
>         return 0;
>  }
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
> index db837f1..07cdd23 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.h
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
> @@ -155,6 +155,7 @@
>  } while (0)
>
>  struct mwifiex_plt_wake_cfg {
> +       struct device *dev;
>         int irq_wifi;
>         bool wake_by_wifi;
>  };
> --
> 2.8.0.rc3.226.g39d4020
>