Linux wireless drivers development
 help / color / mirror / Atom feed
* RE: [PATCH 0/3] Libertas : cfg80211, 11d support
From: Kiran Divekar @ 2010-06-05  6:30 UTC (permalink / raw)
  To: John W. Linville
  Cc: libertas-dev@lists.infradead.org, linux-wireless@vger.kernel.org,
	Amitkumar Karwar
In-Reply-To: <20100604192639.GC2492@tuxdriver.com>

> > Kiran Divekar (3):
> >   Libertas: cfg80211 support
> >   Libertas: fix WARN_ON issues in cfg80211 support
> >   Libertas: Added 11d support using cfg80211
> 
> This series no longer applies.  Would you care to rebase it again? :-)
> 

I rebased the patches and sent to mailing list.

> Thanks!
> 
> John

Thanks
- Kiran


^ permalink raw reply

* Re: [PATCH 1/2] wl1251: fix a memory leak in probe
From: Kalle Valo @ 2010-06-05  7:00 UTC (permalink / raw)
  To: Grazvydas Ignotas; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1275693948-3189-1-git-send-email-notasas@gmail.com>

On 5 June 2010 02:25, Grazvydas Ignotas <notasas@gmail.com> wrote:
> wl1251_sdio_probe() error path is missing wl1251_free_hw, add it.

Looks good, thanks.

> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>

Acked-by: Kalle Valo <kvalo@adurom.com>

^ permalink raw reply

* Re: [PATCH 2/2] wl1251: fix ELP_CTRL register reads
From: Kalle Valo @ 2010-06-05  7:04 UTC (permalink / raw)
  To: Grazvydas Ignotas; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1275693948-3189-2-git-send-email-notasas@gmail.com>

On 5 June 2010 02:25, Grazvydas Ignotas <notasas@gmail.com> wrote:
> Reading the ELP_CTRL register with sdio_readb causes problems because
> hardware seems to be performing a write using stuff bits in the request
> (those bits contain write data in write request). This indicates that it
> actually expects RAW (read after write) type of request, so perform that
> when reading ELP_CTRL instead. Also cache last written value so we know
> what to write when doing RAW request.
>
> Because of the above it was not possible to wake the chip from ELP power
> saving mode, PM had to be disabled to have the driver usable in SDIO
> mode. After this patch PM is functional.

Excellent that Power Save is now working SDIO. Thank you very much!

> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>

Acked-by: Kalle Valo <kvalo@adurom.com>

> this patch is not suitable for backporting because reqiured SDIO function
> was only merged during the last merge window.

Usually information like this is good to store in the commit log
itself so that it gets properly archived.

Kalle

^ permalink raw reply

* Re: [stable][PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Luis R. Rodriguez @ 2010-06-05  7:20 UTC (permalink / raw)
  To: Vivek Natarajan; +Cc: greg, stable, linux-wireless, Ranga Rao Ravuri
In-Reply-To: <1275642369-5024-1-git-send-email-vnatarajan@atheros.com>

On Fri, Jun 4, 2010 at 2:06 AM, Vivek Natarajan <vnatarajan@atheros.com> wrote:
> If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
> with WEP or TKIP, eventhough the received frame may be a CRC failed
> corrupted frame. If this bit is set, H/W obeys key type in keycache.
> If it is not set and if the key type in keycache is neither open nor
> AES, H/W forces key type to be open.  But bit 29 should be set to 1
> for AsyncFIFO feature to encrypt/decrypt the aggregate with WEP or TKIP.
>
> Reported-by: Johan Hovold <johan.hovold@lundinova.se>
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
> Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
> ---
> Applies on top of 2.6.33 and 2.6.34

You need to Cc: stable@kernel.org on the commit log.

  Luis

^ permalink raw reply

* Re: [stable][PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Luis R. Rodriguez @ 2010-06-05  7:20 UTC (permalink / raw)
  To: Vivek Natarajan; +Cc: greg, stable, linux-wireless, Ranga Rao Ravuri
In-Reply-To: <AANLkTildAN_AYlUV6l34TcWdVVelRIn9sWe5IEaLO5fS@mail.gmail.com>

On Sat, Jun 5, 2010 at 12:20 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Jun 4, 2010 at 2:06 AM, Vivek Natarajan <vnatarajan@atheros.com> wrote:
>> If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
>> with WEP or TKIP, eventhough the received frame may be a CRC failed
>> corrupted frame. If this bit is set, H/W obeys key type in keycache.
>> If it is not set and if the key type in keycache is neither open nor
>> AES, H/W forces key type to be open.  But bit 29 should be set to 1
>> for AsyncFIFO feature to encrypt/decrypt the aggregate with WEP or TKIP.
>>
>> Reported-by: Johan Hovold <johan.hovold@lundinova.se>
>> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>> Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
>> ---
>> Applies on top of 2.6.33 and 2.6.34
>
> You need to Cc: stable@kernel.org on the commit log.

Does 2.6.32 not have this issue?

  Luis

^ permalink raw reply

* Re: [stable][PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Luis R. Rodriguez @ 2010-06-05  7:21 UTC (permalink / raw)
  To: Vivek Natarajan; +Cc: greg, stable, linux-wireless, Ranga Rao Ravuri
In-Reply-To: <AANLkTimorQtjCmyiTpimfa4qx0F-cSLaQNO0V4Dv8CH3@mail.gmail.com>

On Sat, Jun 5, 2010 at 12:20 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Sat, Jun 5, 2010 at 12:20 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Fri, Jun 4, 2010 at 2:06 AM, Vivek Natarajan <vnatarajan@atheros.com> wrote:
>>> If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
>>> with WEP or TKIP, eventhough the received frame may be a CRC failed
>>> corrupted frame. If this bit is set, H/W obeys key type in keycache.
>>> If it is not set and if the key type in keycache is neither open nor
>>> AES, H/W forces key type to be open.  But bit 29 should be set to 1
>>> for AsyncFIFO feature to encrypt/decrypt the aggregate with WEP or TKIP.
>>>
>>> Reported-by: Johan Hovold <johan.hovold@lundinova.se>
>>> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>>> Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
>>> ---
>>> Applies on top of 2.6.33 and 2.6.34
>>
>> You need to Cc: stable@kernel.org on the commit log.
>
> Does 2.6.32 not have this issue?

If not, why not?

  Luis

^ permalink raw reply

* [PATCH] libertas: Fix ethtool reporting no WOL options supported if WOL is not already active
From: Sascha Silbe @ 2010-06-05 11:30 UTC (permalink / raw)
  To: linux-wireless

This patch fixes the libertas driver incorrectly reporting that Wake-on-LAN
is not supported if Wake-on-LAN is currently disabled.

Signed-off-by: Sascha Silbe <sascha-pgp@silbe.org>
Acked-by: Dan Williams <dcbw@redhat.com>
---
 drivers/net/wireless/libertas/ethtool.c |    9 +++------
 1 files changed, 3 insertions(+), 6 deletions(-)

Resend with Acked-By Dan and Signed-Off-By, no other changes.

Without patch:

root@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
        Supports Wake-on: d
        Wake-on: d
root@xo15-minimal:~# ethtool -s wlan0 wol pum
root@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
        Supports Wake-on: pumb
        Wake-on: pum
root@xo15-minimal:~# ethtool -s wlan0 wol d
root@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
        Supports Wake-on: d
        Wake-on: d
root@xo15-minimal:~# 


With patch:

xo-sascha:~# ethtool eth0
Settings for eth0:
        Supports Wake-on: pumb
        Wake-on: d
xo-sascha:~# ethtool -s eth0 wol pum
xo-sascha:~# ethtool eth0
Settings for eth0:
        Supports Wake-on: pumb
        Wake-on: pum
xo-sascha:~# ethtool -s eth0 wol d
xo-sascha:~# ethtool eth0
Settings for eth0:
        Supports Wake-on: pumb
        Wake-on: d

diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
index 6eb9a88..4a337b7 100644
--- a/drivers/net/wireless/libertas/ethtool.c
+++ b/drivers/net/wireless/libertas/ethtool.c
@@ -145,14 +145,11 @@ static void lbs_ethtool_get_wol(struct net_device *dev,
 {
 	struct lbs_private *priv = dev->ml_priv;
 
-	if (priv->wol_criteria == 0xffffffff) {
-		/* Interface driver didn't configure wake */
-		wol->supported = wol->wolopts = 0;
-		return;
-	}
-
 	wol->supported = WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY;
 
+	if (priv->wol_criteria == EHS_REMOVE_WAKEUP)
+		return;
+
 	if (priv->wol_criteria & EHS_WAKE_ON_UNICAST_DATA)
 		wol->wolopts |= WAKE_UCAST;
 	if (priv->wol_criteria & EHS_WAKE_ON_MULTICAST_DATA)
-- 
1.6.5


^ permalink raw reply related

* Re: [PATCH] libertas: Fix ethtool reporting no WOL options supported if WOL is not already active
From: Sascha Silbe @ 2010-06-05 11:37 UTC (permalink / raw)
  To: linux-wireless
In-Reply-To: <1275457005.18302.1.camel@localhost.localdomain>

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

Excerpts from Dan Williams's message of Wed Jun 02 05:36:45 +0000 2010:

> Acked-by: Dan Williams <dcbw@redhat.com>
Thanks!

> but note that this patch submission isn't correctly formatted, you'll
> need to add your Signed-off-by tag as described here:
Oops, "tg patch" usually does that for me, but I've used git format-patch for this patch. I've just resent it with SOB and Acked-By added.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply

* Re: Conversion of driver for Realtek 8192SU
From: Frederic Leroy @ 2010-06-05 18:50 UTC (permalink / raw)
  To: Larry Finger; +Cc: John Linville, Greg KH, wireless
In-Reply-To: <4BFE9A22.5040005@lwfinger.net>

Le Thu, 27 May 2010 11:13:22 -0500,
Larry Finger <Larry.Finger@lwfinger.net> a écrit :

> I am in the process of converting the driver contained in the file
> RTL8192SU_usb_linux_v2.6.0006.20100511.zip obtained from the Realtek
> site. This driver is used for the following USB IDs:
> 
> Realtek (0x0bda)  0x8171, 0x8172, 0x8173, 0x8174, 0x8712,
> 0x8713,
> [...]
> My test device is a D-Link DWA-130 (14b2:3300). The Realtek driver
> compiles cleanly and works as-is for this device on i386 architecture;

I own a Trendnet TEW-649UB (usb ids : 0bda:8172).
I got the staging driver working only once. Since then, I found that the
function which sets the channel didn't work.
The 20100511 driver has the same behaviour at first sight, looking at
wireshark trace.

> My initial plan is to modify this driver code for inclusion in
> drivers/staging. The above list includes some, but not all, of the IDs
> in the driver currently in drivers/staging/rtl8192su. I will likely
> put this in as drivers/staging/rtl8712u, which is the name used in
> the code, and remove the duplicate IDs from rtl8192su. Once this step
> is done, I will then work at modifying it to use mac80211 so that it
> can go into mainline.

Some work has been made in the staging driver. Can it be a better
start ?

Have you a repository with your work ? I would like to test it again my
device and if possible join our effort.

-- 
Frédéric Leroy

^ permalink raw reply

* Compat-wireless release for 2010-06-05 is baked
From: Compat-wireless cronjob account @ 2010-06-05 19:05 UTC (permalink / raw)
  To: mcgrof, linux-wireless, linux-bluetooth


compat-wireless code metrics

    495683 - Total upstream code being pulled
      1393 - backport code changes
      1163 - backport code additions
       230 - backport code deletions
      5685 - backport from compat module
      7078 - total backport code
      1.43 - % of code consists of backport work
      1222 - Crap changes not yet posted
      1181 - Crap additions not yet merged
        41 - Crap deletions not yet posted
      0.25 - % of crap code

Base tree: linux-next.git
Base tree version: next-20100604
compat-wireless release: compat-wireless-2010-06-04

^ permalink raw reply

* [PATCH] add support for Dell WLA3310 USB card
From: Jason Dravet @ 2010-06-05 19:04 UTC (permalink / raw)
  To: linux-wireless


Hi,

The Dell WLA3310 USB wireless card has a Z-Com XG-705A chipset that p54 supports with this patch.  You also have to get the firmware from
http://wireless.kernel.org/en/users/Drivers/p54 
download 2.13.24.0.lm87.arm (USB 2nd generation (ISL3887)), rename it to
isl3887usb and put it in /lib/firmware.

The only problem I see is the LED light goes on when I plug the card in and it goes out when I get a dhcp address (dhclient).  The LED doesn't flicker when I ping the router either.  The other funny thing it has two LEDs, one on top and one on the bottom.  It appears they do the same thing i.e. they are both on or both off.

Please consider applying for 2.6.35 and stable depending on if you can distribute the firmware.  If you need anything else please let me know.

Thanks,
Jason Dravet

Signed-off-by: Jason Dravet <dravet@hotmail.com>
Tested-by: Richard Gregory Tillmore <rtillmore@gmail.com>

diff -c p54usb2.c p54usb.c>wla3310.patch

*** p54usb2.c    Fri Jun  4 21:54:16 2010
--- p54usb.c    Fri Jun  4 21:54:06 2010
***************
*** 82,87 ****
--- 82,88 ----
      {USB_DEVICE(0x2001, 0x3704)},    /* DLink DWL-G122 rev A2 */
      {USB_DEVICE(0x413c, 0x8102)},    /* Spinnaker DUT */
      {USB_DEVICE(0x413c, 0x8104)},    /* Cohiba Proto board */
+     {USB_DEVICE(0x413c, 0x5513)},    /* Dell WLA3310 USB Wireless Adapter */
      {}
  };
  

 		 	   		  
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3

^ permalink raw reply

* Re: [PATCH] add support for Dell WLA3310 USB card
From: Larry Finger @ 2010-06-05 19:55 UTC (permalink / raw)
  To: Jason Dravet; +Cc: linux-wireless
In-Reply-To: <SNT144-w4640D712F57F1472EF0A16DFD30@phx.gbl>

On 06/05/2010 02:04 PM, Jason Dravet wrote:
> 
> Hi,
> 
> The Dell WLA3310 USB wireless card has a Z-Com XG-705A chipset that p54 supports with this patch.  You also have to get the firmware from
> http://wireless.kernel.org/en/users/Drivers/p54 
> download 2.13.24.0.lm87.arm (USB 2nd generation (ISL3887)), rename it to
> isl3887usb and put it in /lib/firmware.
> 
> The only problem I see is the LED light goes on when I plug the card in and it goes out when I get a dhcp address (dhclient).  The LED doesn't flicker when I ping the router either.  The other funny thing it has two LEDs, one on top and one on the bottom.  It appears they do the same thing i.e. they are both on or both off.
> 
> Please consider applying for 2.6.35 and stable depending on if you can distribute the firmware.  If you need anything else please let me know.
> 
> Thanks,
> Jason Dravet
> 
> Signed-off-by: Jason Dravet <dravet@hotmail.com>
> Tested-by: Richard Gregory Tillmore <rtillmore@gmail.com>
> 
> diff -c p54usb2.c p54usb.c>wla3310.patch
> 
> *** p54usb2.c    Fri Jun  4 21:54:16 2010
> --- p54usb.c    Fri Jun  4 21:54:06 2010
> ***************
> *** 82,87 ****
> --- 82,88 ----
>       {USB_DEVICE(0x2001, 0x3704)},    /* DLink DWL-G122 rev A2 */
>       {USB_DEVICE(0x413c, 0x8102)},    /* Spinnaker DUT */
>       {USB_DEVICE(0x413c, 0x8104)},    /* Cohiba Proto board */
> +     {USB_DEVICE(0x413c, 0x5513)},    /* Dell WLA3310 USB Wireless Adapter */
>       {}
>   };

Thanks for looking to this, but you need read
Documentation/SubmittingPatches and follow the guidelines, otherwise you
cause considerable extra work for John Linville.

This time, I will reformat the patch for you.

Larry

^ permalink raw reply

* [PATCH] p54usb: Add device ID for Dell WLA3310 USB
From: Larry Finger @ 2010-06-05 20:08 UTC (permalink / raw)
  To: John W Linville, chunkeey; +Cc: dravet, linux-wireless

From: Jason Dravet <dravet@hotmail.com>

Add Dell WLA3310 USB wireless card, which has a Z-Com XG-705A chipset, to the
USB Ids in p54usc.

Signed-off-by: Jason Dravet <dravet@hotmail.com>
Tested-by: Richard Gregory Tillmore <rtillmore@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---

John,

Please submit this update for 2.6.35.

Jason reports "The only problem I see is the LED light goes on when I plug
the card in and it goes out when I get a dhcp address (dhclient).  The LED
doesn't flicker when I ping the router either. The other funny thing it has
two LEDs, one on top and one on the bottom. It appears they do the same thing
i.e. they are both on or both off." From this I conclude that this driver may
need some additional tweaking to support LEDs, but that is of secondary
importance.

Larry
---

Index: wireless-testing/drivers/net/wireless/p54/p54usb.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/p54/p54usb.c
+++ wireless-testing/drivers/net/wireless/p54/p54usb.c
@@ -80,6 +80,7 @@ static struct usb_device_id p54u_table[]
 	{USB_DEVICE(0x1413, 0x5400)},   /* Telsey 802.11g USB2.0 Adapter */
 	{USB_DEVICE(0x1435, 0x0427)},	/* Inventel UR054G */
 	{USB_DEVICE(0x2001, 0x3704)},	/* DLink DWL-G122 rev A2 */
+	{USB_DEVICE(0x413c, 0x5513)},	/* Dell WLA3310 USB Wireless Adapter */
 	{USB_DEVICE(0x413c, 0x8102)},	/* Spinnaker DUT */
 	{USB_DEVICE(0x413c, 0x8104)},	/* Cohiba Proto board */
 	{}

^ permalink raw reply

* Re: [PATCH] p54usb: Add device ID for Dell WLA3310 USB
From: Christian Lamparter @ 2010-06-05 20:30 UTC (permalink / raw)
  To: Larry Finger; +Cc: John W Linville, dravet, linux-wireless
In-Reply-To: <4c0aaebd.7lqiusTk9vdkgjCd%Larry.Finger@lwfinger.net>

On Saturday 05 June 2010 22:08:29 Larry Finger wrote:
> From: Jason Dravet <dravet@hotmail.com>
> 
> Add Dell WLA3310 USB wireless card, which is based on
> Z-Com XG-705A and has an ISL3887 chipset, to the USB Ids
> in p54usb.
> 
> Signed-off-by: Jason Dravet <dravet@hotmail.com>
> Tested-by: Richard Gregory Tillmore <rtillmore@gmail.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Cc: <stable@kernel.org>

> ---
> 
> Index: wireless-testing/drivers/net/wireless/p54/p54usb.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/p54/p54usb.c
> +++ wireless-testing/drivers/net/wireless/p54/p54usb.c
> @@ -80,6 +80,7 @@ static struct usb_device_id p54u_table[]
>  	{USB_DEVICE(0x1413, 0x5400)},   /* Telsey 802.11g USB2.0 Adapter */
>  	{USB_DEVICE(0x1435, 0x0427)},	/* Inventel UR054G */
>  	{USB_DEVICE(0x2001, 0x3704)},	/* DLink DWL-G122 rev A2 */
> +	{USB_DEVICE(0x413c, 0x5513)},	/* Dell WLA3310 USB Wireless Adapter */
>  	{USB_DEVICE(0x413c, 0x8102)},	/* Spinnaker DUT */
>  	{USB_DEVICE(0x413c, 0x8104)},	/* Cohiba Proto board */
>  	{}
> 

^ permalink raw reply

* Re: iwl6050 firmware?
From: Andy Isaacson @ 2010-06-05 23:32 UTC (permalink / raw)
  To: linux-kernel, linux-wireless
  Cc: Jay Sternberg, Greg KH, drago01, reinette chatre,
	Gábor Stefanik
In-Reply-To: <20100323221350.GA20509@hexapodia.org>

On Tue, Mar 23, 2010 at 03:13:50PM -0700, Andy Isaacson wrote:
> It's been several months since iwl6050 support was merged to mainline,
> 
>     commit e1228374d648efe451973bc5f3d1f9a8e943ec0b
>     Author: Jay Sternberg <jay.e.sternberg@linux.intel.com>
>     Date:   Mon Jan 19 15:30:34 2009 -0800
> 
> 	iwlwifi: add recognition of Intel WiFi Link 6000 and 6050 Series
> 
> and hardware is shipping,
> 
> 02:00.0 Network controller: Intel Corporation WiMAX/WiFi Link 6050 Series (rev 35)
> 
> but the firmware isn't yet in linux-firmware.git nor on
> intellinuxwireless.org.
> 
> Any ETA on a release?

FWIW, iwlwifi-6050-ucode-9.201.4.1.tgz was released this past week, and
is working fine on my "Advanced-N + WiMAX 6250" 8086:0089 (rev 35) with
2.6.35-rc1-00194-gaef4b9a.

-andy

^ permalink raw reply

* RE: [PATCH] add support for Dell WLA3310 USB card
From: Jason Dravet @ 2010-06-05 23:43 UTC (permalink / raw)
  Cc: linux-wireless
In-Reply-To: <4C0AABA8.9010401@lwfinger.net>


> On 06/05/2010 02:55 PM, Larry Finger wrote:
> On 06/05/2010 02:04 PM, Jason Dravet wrote:
>>
>> The Dell WLA3310 USB wireless card has a Z-Com XG-705A chipset that p54 supports with this patch. You also have to get the firmware from
>> http://wireless.kernel.org/en/users/Drivers/p54
>> download 2.13.24.0.lm87.arm (USB 2nd generation (ISL3887)), rename it to
>> isl3887usb and put it in /lib/firmware.
>>
>> The only problem I see is the LED light goes on when I plug the card in and it goes out when I get a dhcp address (dhclient). The LED doesn't flicker when I ping the router either. The other funny thing it has two LEDs, one on top and one on the bottom. It appears they do the same thing i.e. they are both on or both off.
>>
>> Please consider applying for 2.6.35 and stable depending on if you can distribute the firmware. If you need anything else please let me know.
>>
>> Thanks,
>> Jason Dravet
>>
>> Signed-off-by: Jason Dravet 
>> Tested-by: Richard Gregory Tillmore 
>>
>> diff -c p54usb2.c p54usb.c>wla3310.patch
>>
>> *** p54usb2.c Fri Jun 4 21:54:16 2010
>> --- p54usb.c Fri Jun 4 21:54:06 2010
>> ***************
>> *** 82,87 ****
>> --- 82,88 ----
>> {USB_DEVICE(0x2001, 0x3704)}, /* DLink DWL-G122 rev A2 */
>> {USB_DEVICE(0x413c, 0x8102)}, /* Spinnaker DUT */
>> {USB_DEVICE(0x413c, 0x8104)}, /* Cohiba Proto board */
>> + {USB_DEVICE(0x413c, 0x5513)}, /* Dell WLA3310 USB Wireless Adapter */
>> {}
>> };
>
> Thanks for looking to this, but you need read
> Documentation/SubmittingPatches and follow the guidelines, otherwise you
> cause considerable extra work for John Linville.
>
> This time, I will reformat the patch for you.
>
> Larry
 
Thank you Larry.  I appreciate it.  I will RTFM for next time.  How is the firmware issue going to be solved?
 
Thanks,
Jason 		 	   		  
_________________________________________________________________
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1

^ permalink raw reply

* Re: [PATCH] add support for Dell WLA3310 USB card
From: Larry Finger @ 2010-06-05 23:55 UTC (permalink / raw)
  To: Jason Dravet; +Cc: linux-wireless
In-Reply-To: <SNT144-w576DCA1E748A7C631A1B77DFD30@phx.gbl>

On 06/05/2010 06:43 PM, Jason Dravet wrote:
>  
> Thank you Larry.  I appreciate it.  I will RTFM for next time.  How is the firmware issue going to be solved?
>  

The user will need to sort that out. The driver will tell them what file
name should be used. That kind of info should not be in the commit
message as the users would not see it, and the developers do not need
it. The wiki is a better place.

Larry

^ permalink raw reply

* [Patch] Enable rt2800usb in compat-wireless stable branch
From: Richard Farina @ 2010-06-06  5:32 UTC (permalink / raw)
  To: linux-wireless, Luis R. Rodriguez

This patch enables the new RT307x and RT357x chips in compat-wireless 
stable.  I'd like to enable the same for rt2800pci as well but right now 
it doesn't seem to build so I'll wait till it does to submit the diff.

Thanks,
Rick Farina

Don't see why this is needed to patch config.mk but:
Signed-off-by: Rick Farina


Enable rt3[05]7x support in compat-wireless stable branch.
diff -Naur compat-wireless-2.6.35-rc1/config.mk 
compat-wireless-2.6.35-rc1-fixed/config.mk
--- compat-wireless-2.6.35-rc1/config.mk        2010-05-31 
18:30:39.000000000 -0400
+++ compat-wireless-2.6.35-rc1-fixed/config.mk  2010-06-05 
23:48:50.000000000 -0400
@@ -366,9 +366,9 @@
 CONFIG_RT2500USB=m
 ifneq ($(CONFIG_CRC_CCITT),)
 CONFIG_RT2800USB=m
-# CONFIG_RT2800USB_RT30XX=y
-# CONFIG_RT2800USB_RT35XX=y
-# CONFIG_RT2800USB_UNKNOWN=y
+CONFIG_RT2800USB_RT30XX=y
+CONFIG_RT2800USB_RT35XX=y
+CONFIG_RT2800USB_UNKNOWN=y
 endif
 CONFIG_RT2X00_LIB_USB=m
 NEED_RT2X00=y


^ permalink raw reply

* Locking in new ARP query filtering patch
From: reinette chatre @ 2010-06-06  5:33 UTC (permalink / raw)
  To: juuso.oikarinen; +Cc: johannes, linux-wireless

Hi Juuso,

The new "mac80211: Add support for hardware ARP query filtering" is
triggering some issues in my environment. I am not familiar with details
of mac80211 locking and can thus not say if it is an issue with this
patch itself or something in iwlwifi that is exposed by it. Could you
please help take a look?

When running with "mac80211: Add support for hardware ARP query
filtering" I get the following lockdep warning when unloading iwl3945.
The issue was bisected to this patch and when reverted this warning
disappears. I also got a kernel BUG in what appears to be the locking
code, which also did not appear since I reverted this patch.

Here is the lockdep warning:
[   92.026800] =======================================================
[   92.030507] [ INFO: possible circular locking dependency detected ]
[   92.030507] 2.6.34-04781-g2b2c009 #85
[   92.030507] -------------------------------------------------------
[   92.030507] modprobe/5225 is trying to acquire lock:
[   92.030507]  ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq
ueue+0x0/0xb0
[   92.030507]
[   92.030507] but task is already holding lock:
[   92.030507]  (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
[   92.030507]
[   92.030507] which lock already depends on the new lock.
[   92.030507]
[   92.030507]
[   92.030507] the existing dependency chain (in reverse order) is:
[   92.030507]
[   92.030507] -> #2 (rtnl_mutex){+.+.+.}:
[   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
[   92.030507]        [<ffffffff81341754>] mutex_lock_nested+0x44/0x300
[   92.030507]        [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
[   92.030507]        [<ffffffffa022d47c>] ieee80211_assoc_done+0x6c/0xe0 [mac80211]
[   92.030507]        [<ffffffffa022f2ad>] ieee80211_work_work+0x31d/0x1280 [mac80211]
[   92.030507]        [<ffffffff8105a520>] worker_thread+0x230/0x370
[   92.030507]        [<ffffffff8105ecc6>] kthread+0x96/0xb0
[   92.030507]        [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
[   92.030507]
[   92.030507] -> #1 ((&local->work_work)){+.+.+.}:
[   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
[   92.030507]        [<ffffffff8105a51a>] worker_thread+0x22a/0x370
[   92.030507]        [<ffffffff8105ecc6>] kthread+0x96/0xb0
[   92.030507]        [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
[   92.030507]
[   92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}:
[   92.030507]        [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50
[   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
[   92.030507]        [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0
[   92.030507]        [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211]
[   92.030507]        [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211]
[   92.030507]        [<ffffffff812acdfc>] __dev_close+0x4c/0x80
[   92.030507]        [<ffffffff812ace4a>] dev_close+0x1a/0x50
[   92.030507]        [<ffffffff812acf4a>] rollback_registered_many+0xca/0x2e0
[   92.030507]        [<ffffffff812ad176>] unregister_netdevice_many+0x16/0x70
[   92.030507]        [<ffffffffa0230713>] ieee80211_remove_interfaces+0xb3/0xf0 [mac80211]
[   92.030507]        [<ffffffffa02200ae>] ieee80211_unregister_hw+0x4e/0x110 [mac80211]
[   92.030507]        [<ffffffffa0308e00>] iwl3945_pci_remove+0x90/0x79a [iwl3945]
[   92.030507]        [<ffffffff811d5c02>] pci_device_remove+0x32/0x60
[   92.030507]        [<ffffffff8124f11a>] __device_release_driver+0x7a/0xe0
[   92.030507]        [<ffffffff8124f238>] driver_detach+0xb8/0xc0
[   92.030507]        [<ffffffff8124e034>] bus_remove_driver+0x94/0x100
[   92.030507]        [<ffffffff8124f858>] driver_unregister+0x58/0x90
[   92.030507]        [<ffffffff811d5eb8>] pci_unregister_driver+0x48/0xc0
[   92.030507]        [<ffffffffa030951a>] iwl3945_exit+0x10/0x17 [iwl3945]
[   92.030507]        [<ffffffff810800f7>] sys_delete_module+0x167/0x250
[   92.030507]        [<ffffffff81002c6b>] system_call_fastpath+0x16/0x1b
[   92.030507]   
[   92.030507] other info that might help us debug this:
[   92.030507]   
[   92.030507] 1 lock held by modprobe/5225:
[   92.030507]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
[   92.030507]   
[   92.030507] stack backtrace:
[   92.030507] Pid: 5225, comm: modprobe Not tainted 2.6.34-04781-g2b2c009 #85
[   92.030507] Call Trace:
[   92.030507]  [<ffffffff81073d41>] print_circular_bug+0x101/0x110
[   92.030507]  [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50
[   92.030507]  [<ffffffff813432eb>] ? _raw_spin_unlock_irq+0x2b/0x40
[   92.030507]  [<ffffffff81073215>] ? trace_hardirqs_on_caller+0x135/0x180
[   92.030507]  [<ffffffff8105b14e>] ? __cancel_work_timer+0xfe/0x230
[   92.030507]  [<ffffffff810761fb>] lock_acquire+0xdb/0x110
[   92.030507]  [<ffffffff8105b5c0>] ? flush_workqueue+0x0/0xb0
[   92.030507]  [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0
[   92.030507]  [<ffffffff8105b5c0>] ? flush_workqueue+0x0/0xb0
[   92.030507]  [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211]
[   92.030507]  [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211]
[   92.030507]  [<ffffffffa02312ae>] ? ieee80211_stop+0x5e/0x680 [mac80211]
[   92.030507]  [<ffffffff812c1e55>] ? dev_deactivate+0x1c5/0x1f0
[   92.030507]  [<ffffffff812acdfc>] __dev_close+0x4c/0x80
[   92.030507]  [<ffffffff812ace4a>] dev_close+0x1a/0x50
[   92.030507]  [<ffffffff812acf4a>] rollback_registered_many+0xca/0x2e0
[   92.030507]  [<ffffffff812ad176>] unregister_netdevice_many+0x16/0x70
[   92.030507]  [<ffffffffa0230713>] ieee80211_remove_interfaces+0xb3/0xf0 [mac80211]
[   92.030507]  [<ffffffffa02200ae>] ieee80211_unregister_hw+0x4e/0x110 [mac80211]
[   92.030507]  [<ffffffffa0308e00>] iwl3945_pci_remove+0x90/0x79a [iwl3945]
[   92.030507]  [<ffffffff81063cfe>] ? up_read+0x1e/0x40
[   92.030507]  [<ffffffff811d5c02>] pci_device_remove+0x32/0x60
[   92.030507]  [<ffffffff8124f11a>] __device_release_driver+0x7a/0xe0
[   92.030507]  [<ffffffff8124f238>] driver_detach+0xb8/0xc0
[   92.030507]  [<ffffffff8124e034>] bus_remove_driver+0x94/0x100
[   92.030507]  [<ffffffff8124f858>] driver_unregister+0x58/0x90
[   92.030507]  [<ffffffff811d5eb8>] pci_unregister_driver+0x48/0xc0
[   92.030507]  [<ffffffffa030951a>] iwl3945_exit+0x10/0x17 [iwl3945]
[   92.030507]  [<ffffffff810800f7>] sys_delete_module+0x167/0x250
[   92.030507]  [<ffffffff81343729>] ? retint_swapgs+0xe/0x13
[   92.030507]  [<ffffffff81073215>] ? trace_hardirqs_on_caller+0x135/0x180
[   92.030507]  [<ffffffff81342a02>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[   92.030507]  [<ffffffff81002c6b>] system_call_fastpath+0x16/0x1b


Here is the BUG:

[  132.460013] kernel BUG at /home/wifi/iwlwifi-2.6/net/mac80211/main.c:380!
[  132.460013] invalid opcode: 0000 [#1] SMP
[  132.460013] last sysfs file: /sys/devices/virtual/misc/rfkill/dev
[  132.460013] CPU 0
[  132.460013] Modules linked in: iwl3945(+) iwlcore mac80211 cfg80211 rfkill binfmt_misc ipv
6 sbs sbshc psmouse serio_raw pcspkr evdev pegasus mii battery container video output ac proc
essor intel_agp button ext3 jbd mbcache sg sd_mod sr_mod cdrom ahci libahci libata ehci_hcd s
csi_mod uhci_hcd usbcore thermal fan thermal_sys
[  132.460013]
[  132.460013] Pid: 5186, comm: modprobe Not tainted 2.6.35-rc1-wl-63997-gca0217c #206 To be
filled by O.E.M./Montevina platform
[  132.460013] RIP: 0010:[<ffffffffa022fac2>]  [<ffffffffa022fac2>] ieee80211_alloc_hw+0x502/
0x520 [mac80211]
[  132.460013] RSP: 0018:ffff88003a9c7c78  EFLAGS: 00010246
[  132.460013] RAX: ffff880039c61960 RBX: ffff880039c602e0 RCX: 0000000000000001
[  132.460013] RDX: ffffffffa02177a0 RSI: ffffffffa02177a8 RDI: ffffffffa0217a34
[  132.460013] RBP: ffff88003a9c7c98 R08: 0000000000000008 R09: ffffffff815461f8
[  132.460013] R10: 0000000000000001 R11: 0000000000000000 R12: ffff880039c605a0
[  132.460013] R13: ffffffffa0318fc0 R14: ffff88003b616000 R15: ffff88003a8e8000
[  132.460013] FS:  00007f24191876f0(0000) GS:ffff880002000000(0000) knlGS:0000000000000000
[  132.460013] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  132.460013] CR2: 00007ffef6721080 CR3: 000000003aae4000 CR4: 00000000000006f0
[  132.460013] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  132.460013] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  132.460013] Process modprobe (pid: 5186, threadinfo ffff88003a9c6000, task ffff880039a24c9
0)
[  132.460013] Stack:
[  132.460013]  ffffffffa0319480 ffffffffa0319480 ffff88003b616000 ffff88003b616000
[  132.460013] <0> ffff88003a9c7cb8 ffffffffa02af53e ffffffffa0319480 ffff88003b616088
[  132.460013] <0> ffff88003a9c7d38 ffffffffa02fe1a7 0000000000000246 ffffffffa0318f48
[  132.460013] Call Trace:
[  132.460013]  [<ffffffffa02af53e>] iwl_alloc_all+0x1e/0x50 [iwlcore]
[  132.460013]  [<ffffffffa02fe1a7>] iwl3945_pci_probe+0x27/0x1640 [iwl3945]
[  132.460013]  [<ffffffff813446b6>] ? _raw_spin_unlock+0x26/0x30
[  132.460013]  [<ffffffff811d48c0>] ? pci_match_device+0x20/0xd0
[  132.460013]  [<ffffffff811d4772>] local_pci_probe+0x12/0x20
[  132.460013]  [<ffffffff811d5880>] pci_device_probe+0x80/0xa0
[  132.460013]  [<ffffffff8124fa5b>] ? driver_sysfs_add+0x6b/0x90
[  132.460013]  [<ffffffff8124fb95>] driver_probe_device+0x95/0x1d0
[  132.460013]  [<ffffffff8124fd6b>] __driver_attach+0x9b/0xb0
[  132.460013]  [<ffffffff8124fcd0>] ? __driver_attach+0x0/0xb0
[  132.460013]  [<ffffffff8124f23b>] bus_for_each_dev+0x6b/0xa0
[  132.460013]  [<ffffffff8124f9ec>] driver_attach+0x1c/0x20
[  132.460013]  [<ffffffff8124e995>] bus_add_driver+0x1b5/0x300
[  132.460013]  [<ffffffffa0145000>] ? iwl3945_init+0x0/0x80 [iwl3945]
[  132.460013]  [<ffffffff8125007c>] driver_register+0x7c/0x170
[  132.460013]  [<ffffffffa0145000>] ? iwl3945_init+0x0/0x80 [iwl3945]
[  132.460013]  [<ffffffff811d5b3a>] __pci_register_driver+0x6a/0xf0
[  132.460013]  [<ffffffffa0145000>] ? iwl3945_init+0x0/0x80 [iwl3945]
[  132.460013]  [<ffffffffa014504a>] iwl3945_init+0x4a/0x80 [iwl3945]
[  132.460013]  [<ffffffff810001d8>] do_one_initcall+0x38/0x190
[  132.460013]  [<ffffffff810800d4>] sys_init_module+0xe4/0x260
[  132.460013]  [<ffffffff81002c6b>] system_call_fastpath+0x16/0x1b
[  132.460013] Code: c7 c6 9d 12 27 a0 49 89 84 24 a0 03 00 00 49 89 84 24 a8 03 00 00 e8 6e
60 f9 e0 4c 89 e0 5b 41 5c 41 5d 41 5e c9 c3 0f 0b eb fe <0f> 0b eb fe 0f 0b eb fe 0f 0b eb f
e 0f 0b eb fe 0f 0b eb fe 0f
[  132.460013] RIP  [<ffffffffa022fac2>] ieee80211_alloc_hw+0x502/0x520 [mac80211]
[  132.460013]  RSP <ffff88003a9c7c78>
[  132.822653] ---[ end trace 4026d119e16fef57 ]---

The code in which the above appears is:
(gdb) l *(ieee80211_alloc_hw+0x502)
0xaf2 is in ieee80211_alloc_hw (/home/wifi/iwlwifi-2.6/net/mac80211/main.c:380).
375	
376		ifmgd = &sdata->u.mgd;
377		mutex_lock(&ifmgd->mtx);
378		if (ifmgd->associated)
379			ieee80211_set_arp_filter(sdata);
380		mutex_unlock(&ifmgd->mtx);
381	
382		return NOTIFY_DONE;
383	}
384	#endif
(gdb) q

Thank you

Reinette



^ permalink raw reply

* Re: [Patch] Enable rt2800usb in compat-wireless stable branch
From: Luis R. Rodriguez @ 2010-06-06  5:56 UTC (permalink / raw)
  To: Richard Farina; +Cc: linux-wireless
In-Reply-To: <4C0B32E8.4080208@gmail.com>

On Sat, Jun 5, 2010 at 10:32 PM, Richard Farina <sidhayn@gmail.com> wrote:
> This patch enables the new RT307x and RT357x chips in compat-wireless
> stable.  I'd like to enable the same for rt2800pci as well but right now it
> doesn't seem to build so I'll wait till it does to submit the diff.
>
> Thanks,
> Rick Farina
>
> Don't see why this is needed to patch config.mk but:
> Signed-off-by: Rick Farina
>

Manged the patch commit log a bit, but applied it thanks. Will
propagate to 2.6.35.y on the next release.

Thanks!

  Luis

^ permalink raw reply

* [PATCH 0/4] iwlwifi fixes fo 2.6.35
From: Reinette Chatre @ 2010-06-06  6:55 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre

We include four fixes. This series includes the overdue 3945 fix to
internal scanning. The system hang issue fixed by this patch is
encountered by many people, see:
http://thread.gmane.org/gmane.linux.kernel/994562
http://thread.gmane.org/gmane.linux.kernel.wireless.general/51343
http://thread.gmane.org/gmane.linux.kernel.wireless.general/51614
http://thread.gmane.org/gmane.linux.kernel/992191/focus=51561

We include a second fix for iwl3945 that enables a workaround to detect and
recover when the command queue, or a transmit queue, becomes stuck.
Unfortunately users seem to be running into this issue more frequently now.
The bugs related to this issue is noted in the commit message.

A third fix addresses a lockdep warning.

We also include an update to the MAINTAINERS file that we would like to
include in 2.6.35 since Wey-Yi will be maintainer during this
kernel's stabilization as well as thereafter.

These patches are also available from wireless-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git

Abhijeet Kolekar (1):
  iwl3945: fix internal scan

Emmanuel Grumbach (1):
  iwlwifi: move sysfs_create_group to post request firmware

Reinette Chatre (1):
  iwl3945: enable stuck queue detection on 3945

Wey-Yi Guy (1):
  iwlwifi: add name to Maintainers list

 MAINTAINERS                                 |    1 +
 drivers/net/wireless/iwlwifi/iwl-3945.c     |    1 +
 drivers/net/wireless/iwlwifi/iwl-agn-lib.c  |   30 +---
 drivers/net/wireless/iwlwifi/iwl-agn.c      |  318 +++++++++++++-------------
 drivers/net/wireless/iwlwifi/iwl-core.c     |   39 ++++
 drivers/net/wireless/iwlwifi/iwl-core.h     |    2 +
 drivers/net/wireless/iwlwifi/iwl3945-base.c |   56 +++++-
 7 files changed, 257 insertions(+), 190 deletions(-)


^ permalink raw reply

* [PATCH 1/4] iwl3945: enable stuck queue detection on 3945
From: Reinette Chatre @ 2010-06-06  6:56 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, ipw3945-devel, Reinette Chatre
In-Reply-To: <1275807363-18150-1-git-send-email-reinette.chatre@intel.com>

From: Reinette Chatre <reinette.chatre@intel.com>

We learn from
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and
https://bugzilla.redhat.com/show_bug.cgi?id=589777
that 3945 can also suffer from a stuck command queue. Enable stuck queue
detection for iwl3945 to enable recovery in this case.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl-3945.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index 068f7f8..c44a303 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -2852,6 +2852,7 @@ static struct iwl_lib_ops iwl3945_lib = {
 	.isr = iwl_isr_legacy,
 	.config_ap = iwl3945_config_ap,
 	.manage_ibss_station = iwl3945_manage_ibss_station,
+	.recover_from_tx_stall = iwl_bg_monitor_recover,
 	.check_plcp_health = iwl3945_good_plcp_health,
 
 	.debugfs_ops = {
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 2/4] iwl3945: fix internal scan
From: Reinette Chatre @ 2010-06-06  6:56 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, ipw3945-devel, Abhijeet Kolekar, Reinette Chatre
In-Reply-To: <1275807363-18150-1-git-send-email-reinette.chatre@intel.com>

From: Abhijeet Kolekar <abhijeet.kolekar@intel.com>

Port of internal scan to iwl3945 missed introduction
of iwl3945_get_single_channel_for_scan.

Fix the following bug by introducing the iwl3945_get_single_channel_for_scan
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208

Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl-agn-lib.c  |   30 +-------------
 drivers/net/wireless/iwlwifi/iwl-core.c     |   39 ++++++++++++++++++
 drivers/net/wireless/iwlwifi/iwl-core.h     |    2 +
 drivers/net/wireless/iwlwifi/iwl3945-base.c |   56 +++++++++++++++++++++++++-
 4 files changed, 96 insertions(+), 31 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 1004cfc..0f292a2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -1119,10 +1119,9 @@ static int iwl_get_single_channel_for_scan(struct iwl_priv *priv,
 					   struct iwl_scan_channel *scan_ch)
 {
 	const struct ieee80211_supported_band *sband;
-	const struct iwl_channel_info *ch_info;
 	u16 passive_dwell = 0;
 	u16 active_dwell = 0;
-	int i, added = 0;
+	int added = 0;
 	u16 channel = 0;
 
 	sband = iwl_get_hw_mode(priv, band);
@@ -1137,32 +1136,7 @@ static int iwl_get_single_channel_for_scan(struct iwl_priv *priv,
 	if (passive_dwell <= active_dwell)
 		passive_dwell = active_dwell + 1;
 
-	/* only scan single channel, good enough to reset the RF */
-	/* pick the first valid not in-use channel */
-	if (band == IEEE80211_BAND_5GHZ) {
-		for (i = 14; i < priv->channel_count; i++) {
-			if (priv->channel_info[i].channel !=
-			    le16_to_cpu(priv->staging_rxon.channel)) {
-				channel = priv->channel_info[i].channel;
-				ch_info = iwl_get_channel_info(priv,
-					band, channel);
-				if (is_channel_valid(ch_info))
-					break;
-			}
-		}
-	} else {
-		for (i = 0; i < 14; i++) {
-			if (priv->channel_info[i].channel !=
-			    le16_to_cpu(priv->staging_rxon.channel)) {
-					channel =
-						priv->channel_info[i].channel;
-					ch_info = iwl_get_channel_info(priv,
-						band, channel);
-					if (is_channel_valid(ch_info))
-						break;
-			}
-		}
-	}
+	channel = iwl_get_single_channel_number(priv, band);
 	if (channel) {
 		scan_ch->channel = cpu_to_le16(channel);
 		scan_ch->type = SCAN_CHANNEL_TYPE_PASSIVE;
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 5a7eca8..426e955 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -854,6 +854,45 @@ void iwl_set_rxon_chain(struct iwl_priv *priv)
 }
 EXPORT_SYMBOL(iwl_set_rxon_chain);
 
+/* Return valid channel */
+u8 iwl_get_single_channel_number(struct iwl_priv *priv,
+				  enum ieee80211_band band)
+{
+	const struct iwl_channel_info *ch_info;
+	int i;
+	u8 channel = 0;
+
+	/* only scan single channel, good enough to reset the RF */
+	/* pick the first valid not in-use channel */
+	if (band == IEEE80211_BAND_5GHZ) {
+		for (i = 14; i < priv->channel_count; i++) {
+			if (priv->channel_info[i].channel !=
+			    le16_to_cpu(priv->staging_rxon.channel)) {
+				channel = priv->channel_info[i].channel;
+				ch_info = iwl_get_channel_info(priv,
+					band, channel);
+				if (is_channel_valid(ch_info))
+					break;
+			}
+		}
+	} else {
+		for (i = 0; i < 14; i++) {
+			if (priv->channel_info[i].channel !=
+			    le16_to_cpu(priv->staging_rxon.channel)) {
+					channel =
+						priv->channel_info[i].channel;
+					ch_info = iwl_get_channel_info(priv,
+						band, channel);
+					if (is_channel_valid(ch_info))
+						break;
+			}
+		}
+	}
+
+	return channel;
+}
+EXPORT_SYMBOL(iwl_get_single_channel_number);
+
 /**
  * iwl_set_rxon_channel - Set the phymode and channel values in staging RXON
  * @phymode: MODE_IEEE80211A sets to 5.2GHz; all else set to 2.4GHz
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 7e5a5ba..31775bd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -343,6 +343,8 @@ int iwl_check_rxon_cmd(struct iwl_priv *priv);
 int iwl_full_rxon_required(struct iwl_priv *priv);
 void iwl_set_rxon_chain(struct iwl_priv *priv);
 int iwl_set_rxon_channel(struct iwl_priv *priv, struct ieee80211_channel *ch);
+u8 iwl_get_single_channel_number(struct iwl_priv *priv,
+				  enum ieee80211_band band);
 void iwl_set_rxon_ht(struct iwl_priv *priv, struct iwl_ht_config *ht_conf);
 u8 iwl_is_ht40_tx_allowed(struct iwl_priv *priv,
 			 struct ieee80211_sta_ht_cap *sta_ht_inf);
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 3e5bffb..6c353ca 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1844,6 +1844,49 @@ static void iwl3945_irq_tasklet(struct iwl_priv *priv)
 #endif
 }
 
+static int iwl3945_get_single_channel_for_scan(struct iwl_priv *priv,
+					       struct ieee80211_vif *vif,
+					       enum ieee80211_band band,
+					       struct iwl3945_scan_channel *scan_ch)
+{
+	const struct ieee80211_supported_band *sband;
+	u16 passive_dwell = 0;
+	u16 active_dwell = 0;
+	int added = 0;
+	u8 channel = 0;
+
+	sband = iwl_get_hw_mode(priv, band);
+	if (!sband) {
+		IWL_ERR(priv, "invalid band\n");
+		return added;
+	}
+
+	active_dwell = iwl_get_active_dwell_time(priv, band, 0);
+	passive_dwell = iwl_get_passive_dwell_time(priv, band, vif);
+
+	if (passive_dwell <= active_dwell)
+		passive_dwell = active_dwell + 1;
+
+
+	channel = iwl_get_single_channel_number(priv, band);
+
+	if (channel) {
+		scan_ch->channel = channel;
+		scan_ch->type = 0;	/* passive */
+		scan_ch->active_dwell = cpu_to_le16(active_dwell);
+		scan_ch->passive_dwell = cpu_to_le16(passive_dwell);
+		/* Set txpower levels to defaults */
+		scan_ch->tpc.dsp_atten = 110;
+		if (band == IEEE80211_BAND_5GHZ)
+			scan_ch->tpc.tx_gain = ((1 << 5) | (3 << 3)) | 3;
+		else
+			scan_ch->tpc.tx_gain = ((1 << 5) | (5 << 3));
+		added++;
+	} else
+		IWL_ERR(priv, "no valid channel found\n");
+	return added;
+}
+
 static int iwl3945_get_channels_for_scan(struct iwl_priv *priv,
 					 enum ieee80211_band band,
 				     u8 is_active, u8 n_probes,
@@ -2992,9 +3035,16 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
 	/* select Rx antennas */
 	scan->flags |= iwl3945_get_antenna_flags(priv);
 
-	scan->channel_count =
-		iwl3945_get_channels_for_scan(priv, band, is_active, n_probes,
-			(void *)&scan->data[le16_to_cpu(scan->tx_cmd.len)], vif);
+	if (priv->is_internal_short_scan) {
+		scan->channel_count =
+			iwl3945_get_single_channel_for_scan(priv, vif, band,
+				(void *)&scan->data[le16_to_cpu(
+				scan->tx_cmd.len)]);
+	} else {
+		scan->channel_count =
+			iwl3945_get_channels_for_scan(priv, band, is_active, n_probes,
+				(void *)&scan->data[le16_to_cpu(scan->tx_cmd.len)], vif);
+	}
 
 	if (scan->channel_count == 0) {
 		IWL_DEBUG_SCAN(priv, "channel count %d\n", scan->channel_count);
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 4/4] iwlwifi: move sysfs_create_group to post request firmware
From: Reinette Chatre @ 2010-06-06  6:56 UTC (permalink / raw)
  To: linville
  Cc: linux-wireless, ipw3945-devel, Emmanuel Grumbach, Reinette Chatre
In-Reply-To: <1275807363-18150-1-git-send-email-reinette.chatre@intel.com>

From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Move the sysfs_create_group to iwl_ucode_callback after we
have safely got the firmware.

The motivation to do this comes from a warning from lockdep which detected
that we request priv->mutex while holding s_active during a sysfs request
(show_statistics in the example copy pasted). The reverse order exists upon
request_firmware: request_firmware which is a sysfs operation
that requires s_active is run under priv->mutex.

This ensures that we don't get sysfs request before we finish to request
the firmware, avoiding this deadlock.

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
cat/2595 is trying to acquire lock:
 (&priv->mutex){+.+.+.}, at: [<facfa598>] show_statistics+0x48/0x100 [iwlagn]

but task is already holding lock:
 (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (s_active){++++.+}:
       [<c0489b74>] __lock_acquire+0xc44/0x1230
       [<c048a1ed>] lock_acquire+0x8d/0x110
       [<c0581499>] sysfs_addrm_finish+0xe9/0x180
       [<c057f64a>] sysfs_hash_and_remove+0x4a/0x80
       [<c05829d4>] sysfs_remove_group+0x44/0xd0
       [<c0714b75>] dpm_sysfs_remove+0x15/0x20
       [<c070dac8>] device_del+0x38/0x170
       [<c070dc1e>] device_unregister+0x1e/0x60
       [<c071838d>] _request_firmware+0x29d/0x550
       [<c07186c7>] request_firmware+0x17/0x20
       [<fad01bf1>] iwl_mac_start+0xb1/0x1230 [iwlagn]
       [<fa46ba06>] ieee80211_open+0x436/0x6f0 [mac80211]
       [<c0808cd2>] dev_open+0x92/0xf0
       [<c0808b2b>] dev_change_flags+0x7b/0x190
       [<c08148e8>] do_setlink+0x178/0x3b0
       [<c0815169>] rtnl_setlink+0xf9/0x130
       [<c081453b>] rtnetlink_rcv_msg+0x1bb/0x1f0
       [<c0827ce6>] netlink_rcv_skb+0x86/0xa0
       [<c081436c>] rtnetlink_rcv+0x1c/0x30
       [<c08279c3>] netlink_unicast+0x263/0x290
       [<c0828768>] netlink_sendmsg+0x1c8/0x2a0
       [<c07f85fd>] sock_sendmsg+0xcd/0x100
       [<c07f964d>] sys_sendmsg+0x15d/0x290
       [<c07f9e6b>] sys_socketcall+0xeb/0x2a0
       [<c040ad9f>] sysenter_do_call+0x12/0x38

-> #0 (&priv->mutex){+.+.+.}:
       [<c0489f84>] __lock_acquire+0x1054/0x1230
       [<c048a1ed>] lock_acquire+0x8d/0x110
       [<c08bb358>] __mutex_lock_common+0x58/0x470
       [<c08bb84a>] mutex_lock_nested+0x3a/0x50
       [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
       [<c070d219>] dev_attr_show+0x29/0x50
       [<c057fecd>] sysfs_read_file+0xdd/0x190
       [<c052880f>] vfs_read+0x9f/0x190
       [<c0528d22>] sys_read+0x42/0x70
       [<c040ad9f>] sysenter_do_call+0x12/0x38

other info that might help us debug this:

3 locks held by cat/2595:
 #0:  (&buffer->mutex){+.+.+.}, at: [<c057fe25>] sysfs_read_file+0x35/0x190
 #1:  (s_active){++++.+}, at: [<c0580ecd>] sysfs_get_active_two+0x2d/0x50
 #2:  (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50

stack backtrace:
Pid: 2595, comm: cat Not tainted 2.6.33-tp-rc4 #2
Call Trace:
 [<c08b99ab>] ? printk+0x1d/0x22
 [<c0487752>] print_circular_bug+0xc2/0xd0
 [<c0489f84>] __lock_acquire+0x1054/0x1230
 [<c0478d81>] ? sched_clock_cpu+0x121/0x180
 [<c048a1ed>] lock_acquire+0x8d/0x110
 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
 [<c08bb358>] __mutex_lock_common+0x58/0x470
 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
 [<c08bb84a>] mutex_lock_nested+0x3a/0x50
 [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
 [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
 [<c0580cf9>] ? sysfs_get_active+0x69/0xb0
 [<facfa550>] ? show_statistics+0x0/0x100 [iwlagn]
 [<c070d219>] dev_attr_show+0x29/0x50
 [<c057fecd>] sysfs_read_file+0xdd/0x190
 [<c05ff314>] ? security_file_permission+0x14/0x20
 [<c0528242>] ? rw_verify_area+0x62/0xd0
 [<c052880f>] vfs_read+0x9f/0x190
 [<c047745b>] ? up_read+0x1b/0x30
 [<c057fdf0>] ? sysfs_read_file+0x0/0x190
 [<c04af3b4>] ? audit_syscall_entry+0x1f4/0x220
 [<c0528d22>] sys_read+0x42/0x70
 [<c040ad9f>] sysenter_do_call+0x12/0x38

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl-agn.c |  318 ++++++++++++++++----------------
 1 files changed, 159 insertions(+), 159 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index aef4f71..7726e67 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -1484,6 +1484,156 @@ bool iwl_good_ack_health(struct iwl_priv *priv,
 }
 
 
+/*****************************************************************************
+ *
+ * sysfs attributes
+ *
+ *****************************************************************************/
+
+#ifdef CONFIG_IWLWIFI_DEBUG
+
+/*
+ * The following adds a new attribute to the sysfs representation
+ * of this device driver (i.e. a new file in /sys/class/net/wlan0/device/)
+ * used for controlling the debug level.
+ *
+ * See the level definitions in iwl for details.
+ *
+ * The debug_level being managed using sysfs below is a per device debug
+ * level that is used instead of the global debug level if it (the per
+ * device debug level) is set.
+ */
+static ssize_t show_debug_level(struct device *d,
+				struct device_attribute *attr, char *buf)
+{
+	struct iwl_priv *priv = dev_get_drvdata(d);
+	return sprintf(buf, "0x%08X\n", iwl_get_debug_level(priv));
+}
+static ssize_t store_debug_level(struct device *d,
+				struct device_attribute *attr,
+				 const char *buf, size_t count)
+{
+	struct iwl_priv *priv = dev_get_drvdata(d);
+	unsigned long val;
+	int ret;
+
+	ret = strict_strtoul(buf, 0, &val);
+	if (ret)
+		IWL_ERR(priv, "%s is not in hex or decimal form.\n", buf);
+	else {
+		priv->debug_level = val;
+		if (iwl_alloc_traffic_mem(priv))
+			IWL_ERR(priv,
+				"Not enough memory to generate traffic log\n");
+	}
+	return strnlen(buf, count);
+}
+
+static DEVICE_ATTR(debug_level, S_IWUSR | S_IRUGO,
+			show_debug_level, store_debug_level);
+
+
+#endif /* CONFIG_IWLWIFI_DEBUG */
+
+
+static ssize_t show_temperature(struct device *d,
+				struct device_attribute *attr, char *buf)
+{
+	struct iwl_priv *priv = dev_get_drvdata(d);
+
+	if (!iwl_is_alive(priv))
+		return -EAGAIN;
+
+	return sprintf(buf, "%d\n", priv->temperature);
+}
+
+static DEVICE_ATTR(temperature, S_IRUGO, show_temperature, NULL);
+
+static ssize_t show_tx_power(struct device *d,
+			     struct device_attribute *attr, char *buf)
+{
+	struct iwl_priv *priv = dev_get_drvdata(d);
+
+	if (!iwl_is_ready_rf(priv))
+		return sprintf(buf, "off\n");
+	else
+		return sprintf(buf, "%d\n", priv->tx_power_user_lmt);
+}
+
+static ssize_t store_tx_power(struct device *d,
+			      struct device_attribute *attr,
+			      const char *buf, size_t count)
+{
+	struct iwl_priv *priv = dev_get_drvdata(d);
+	unsigned long val;
+	int ret;
+
+	ret = strict_strtoul(buf, 10, &val);
+	if (ret)
+		IWL_INFO(priv, "%s is not in decimal form.\n", buf);
+	else {
+		ret = iwl_set_tx_power(priv, val, false);
+		if (ret)
+			IWL_ERR(priv, "failed setting tx power (0x%d).\n",
+				ret);
+		else
+			ret = count;
+	}
+	return ret;
+}
+
+static DEVICE_ATTR(tx_power, S_IWUSR | S_IRUGO, show_tx_power, store_tx_power);
+
+static ssize_t show_rts_ht_protection(struct device *d,
+			     struct device_attribute *attr, char *buf)
+{
+	struct iwl_priv *priv = dev_get_drvdata(d);
+
+	return sprintf(buf, "%s\n",
+		priv->cfg->use_rts_for_ht ? "RTS/CTS" : "CTS-to-self");
+}
+
+static ssize_t store_rts_ht_protection(struct device *d,
+			      struct device_attribute *attr,
+			      const char *buf, size_t count)
+{
+	struct iwl_priv *priv = dev_get_drvdata(d);
+	unsigned long val;
+	int ret;
+
+	ret = strict_strtoul(buf, 10, &val);
+	if (ret)
+		IWL_INFO(priv, "Input is not in decimal form.\n");
+	else {
+		if (!iwl_is_associated(priv))
+			priv->cfg->use_rts_for_ht = val ? true : false;
+		else
+			IWL_ERR(priv, "Sta associated with AP - "
+				"Change protection mechanism is not allowed\n");
+		ret = count;
+	}
+	return ret;
+}
+
+static DEVICE_ATTR(rts_ht_protection, S_IWUSR | S_IRUGO,
+			show_rts_ht_protection, store_rts_ht_protection);
+
+
+static struct attribute *iwl_sysfs_entries[] = {
+	&dev_attr_temperature.attr,
+	&dev_attr_tx_power.attr,
+	&dev_attr_rts_ht_protection.attr,
+#ifdef CONFIG_IWLWIFI_DEBUG
+	&dev_attr_debug_level.attr,
+#endif
+	NULL
+};
+
+static struct attribute_group iwl_attribute_group = {
+	.name = NULL,		/* put in device directory */
+	.attrs = iwl_sysfs_entries,
+};
+
 /******************************************************************************
  *
  * uCode download functions
@@ -1965,6 +2115,13 @@ static void iwl_ucode_callback(const struct firmware *ucode_raw, void *context)
 	if (err)
 		IWL_ERR(priv, "failed to create debugfs files. Ignoring error: %d\n", err);
 
+	err = sysfs_create_group(&priv->pci_dev->dev.kobj,
+					&iwl_attribute_group);
+	if (err) {
+		IWL_ERR(priv, "failed to create sysfs device attributes\n");
+		goto out_unbind;
+	}
+
 	/* We have our copies now, allow OS release its copies */
 	release_firmware(ucode_raw);
 	complete(&priv->_agn.firmware_loading_complete);
@@ -3264,141 +3421,6 @@ static int iwlagn_mac_sta_add(struct ieee80211_hw *hw,
 
 /*****************************************************************************
  *
- * sysfs attributes
- *
- *****************************************************************************/
-
-#ifdef CONFIG_IWLWIFI_DEBUG
-
-/*
- * The following adds a new attribute to the sysfs representation
- * of this device driver (i.e. a new file in /sys/class/net/wlan0/device/)
- * used for controlling the debug level.
- *
- * See the level definitions in iwl for details.
- *
- * The debug_level being managed using sysfs below is a per device debug
- * level that is used instead of the global debug level if it (the per
- * device debug level) is set.
- */
-static ssize_t show_debug_level(struct device *d,
-				struct device_attribute *attr, char *buf)
-{
-	struct iwl_priv *priv = dev_get_drvdata(d);
-	return sprintf(buf, "0x%08X\n", iwl_get_debug_level(priv));
-}
-static ssize_t store_debug_level(struct device *d,
-				struct device_attribute *attr,
-				 const char *buf, size_t count)
-{
-	struct iwl_priv *priv = dev_get_drvdata(d);
-	unsigned long val;
-	int ret;
-
-	ret = strict_strtoul(buf, 0, &val);
-	if (ret)
-		IWL_ERR(priv, "%s is not in hex or decimal form.\n", buf);
-	else {
-		priv->debug_level = val;
-		if (iwl_alloc_traffic_mem(priv))
-			IWL_ERR(priv,
-				"Not enough memory to generate traffic log\n");
-	}
-	return strnlen(buf, count);
-}
-
-static DEVICE_ATTR(debug_level, S_IWUSR | S_IRUGO,
-			show_debug_level, store_debug_level);
-
-
-#endif /* CONFIG_IWLWIFI_DEBUG */
-
-
-static ssize_t show_temperature(struct device *d,
-				struct device_attribute *attr, char *buf)
-{
-	struct iwl_priv *priv = dev_get_drvdata(d);
-
-	if (!iwl_is_alive(priv))
-		return -EAGAIN;
-
-	return sprintf(buf, "%d\n", priv->temperature);
-}
-
-static DEVICE_ATTR(temperature, S_IRUGO, show_temperature, NULL);
-
-static ssize_t show_tx_power(struct device *d,
-			     struct device_attribute *attr, char *buf)
-{
-	struct iwl_priv *priv = dev_get_drvdata(d);
-
-	if (!iwl_is_ready_rf(priv))
-		return sprintf(buf, "off\n");
-	else
-		return sprintf(buf, "%d\n", priv->tx_power_user_lmt);
-}
-
-static ssize_t store_tx_power(struct device *d,
-			      struct device_attribute *attr,
-			      const char *buf, size_t count)
-{
-	struct iwl_priv *priv = dev_get_drvdata(d);
-	unsigned long val;
-	int ret;
-
-	ret = strict_strtoul(buf, 10, &val);
-	if (ret)
-		IWL_INFO(priv, "%s is not in decimal form.\n", buf);
-	else {
-		ret = iwl_set_tx_power(priv, val, false);
-		if (ret)
-			IWL_ERR(priv, "failed setting tx power (0x%d).\n",
-				ret);
-		else
-			ret = count;
-	}
-	return ret;
-}
-
-static DEVICE_ATTR(tx_power, S_IWUSR | S_IRUGO, show_tx_power, store_tx_power);
-
-static ssize_t show_rts_ht_protection(struct device *d,
-			     struct device_attribute *attr, char *buf)
-{
-	struct iwl_priv *priv = dev_get_drvdata(d);
-
-	return sprintf(buf, "%s\n",
-		priv->cfg->use_rts_for_ht ? "RTS/CTS" : "CTS-to-self");
-}
-
-static ssize_t store_rts_ht_protection(struct device *d,
-			      struct device_attribute *attr,
-			      const char *buf, size_t count)
-{
-	struct iwl_priv *priv = dev_get_drvdata(d);
-	unsigned long val;
-	int ret;
-
-	ret = strict_strtoul(buf, 10, &val);
-	if (ret)
-		IWL_INFO(priv, "Input is not in decimal form.\n");
-	else {
-		if (!iwl_is_associated(priv))
-			priv->cfg->use_rts_for_ht = val ? true : false;
-		else
-			IWL_ERR(priv, "Sta associated with AP - "
-				"Change protection mechanism is not allowed\n");
-		ret = count;
-	}
-	return ret;
-}
-
-static DEVICE_ATTR(rts_ht_protection, S_IWUSR | S_IRUGO,
-			show_rts_ht_protection, store_rts_ht_protection);
-
-
-/*****************************************************************************
- *
  * driver setup and teardown
  *
  *****************************************************************************/
@@ -3550,21 +3572,6 @@ static void iwl_uninit_drv(struct iwl_priv *priv)
 	kfree(priv->scan_cmd);
 }
 
-static struct attribute *iwl_sysfs_entries[] = {
-	&dev_attr_temperature.attr,
-	&dev_attr_tx_power.attr,
-	&dev_attr_rts_ht_protection.attr,
-#ifdef CONFIG_IWLWIFI_DEBUG
-	&dev_attr_debug_level.attr,
-#endif
-	NULL
-};
-
-static struct attribute_group iwl_attribute_group = {
-	.name = NULL,		/* put in device directory */
-	.attrs = iwl_sysfs_entries,
-};
-
 static struct ieee80211_ops iwl_hw_ops = {
 	.tx = iwl_mac_tx,
 	.start = iwl_mac_start,
@@ -3750,11 +3757,6 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 		IWL_ERR(priv, "Error allocating IRQ %d\n", priv->pci_dev->irq);
 		goto out_disable_msi;
 	}
-	err = sysfs_create_group(&pdev->dev.kobj, &iwl_attribute_group);
-	if (err) {
-		IWL_ERR(priv, "failed to create sysfs device attributes\n");
-		goto out_free_irq;
-	}
 
 	iwl_setup_deferred_work(priv);
 	iwl_setup_rx_handlers(priv);
@@ -3788,15 +3790,13 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	err = iwl_request_firmware(priv, true);
 	if (err)
-		goto out_remove_sysfs;
+		goto out_destroy_workqueue;
 
 	return 0;
 
- out_remove_sysfs:
+ out_destroy_workqueue:
 	destroy_workqueue(priv->workqueue);
 	priv->workqueue = NULL;
-	sysfs_remove_group(&pdev->dev.kobj, &iwl_attribute_group);
- out_free_irq:
 	free_irq(priv->pci_dev->irq, priv);
 	iwl_free_isr_ict(priv);
  out_disable_msi:
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 3/4] iwlwifi: add name to Maintainers list
From: Reinette Chatre @ 2010-06-06  6:56 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy, Reinette Chatre
In-Reply-To: <1275807363-18150-1-git-send-email-reinette.chatre@intel.com>

From: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Add "Wey-Yi Guy" to maintainers list for iwlwifi.

Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
 MAINTAINERS |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 22a49e6..8d51903 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3009,6 +3009,7 @@ F:	include/linux/wimax/i2400m.h
 INTEL WIRELESS WIFI LINK (iwlwifi)
 M:	Zhu Yi <yi.zhu@intel.com>
 M:	Reinette Chatre <reinette.chatre@intel.com>
+M:	Wey-Yi Guy <wey-yi.w.guy@intel.com>
 M:	Intel Linux Wireless <ilw@linux.intel.com>
 L:	linux-wireless@vger.kernel.org
 W:	http://intellinuxwireless.org
-- 
1.7.0.4


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox