headers
Richard Knutsson | 1 Oct 02:24
Picon

[PATCH] softmac: Fix compiler-warning

  CC      net/ieee80211/softmac/ieee80211softmac_wx.o
/home/kernel/src/net/ieee80211/softmac/ieee80211softmac_wx.c: In function ‘ieee80211softmac_wx_set_essid’:
/home/kernel/src/net/ieee80211/softmac/ieee80211softmac_wx.c:117: warning: label
‘out’ defined but not used

due to commit: efe870f9f4ad74410a18ecbf0d9ba7c14b50a0fb. Removing the label.

Signed-off-by: Richard Knutsson <ricknu-0@...>
---
Compile-tested

diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 442b987..5742dc8 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -114,7 +114,7 @@ check_assoc_again:
 	sm->associnfo.associating = 1;
 	/* queue lower level code to do work (if necessary) */
 	schedule_delayed_work(&sm->associnfo.work, 0);
-out:
+
 	mutex_unlock(&sm->associnfo.mutex);

 	return 0;
Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Oct 09:04

handle_ba_action

Whoever added this to include/net/mac80211.h forgot to update
the ieee80211_ops comment block.
Permalink | Reply | 1 comment |
headers
Tomas Winkler | 1 Oct 10:41
Picon

Re: handle_ba_action

It will be replaced with something like

#ifdef CONFIG_MAC80211_HT_AGG
        /* move to Tx aggregation for a certain DA/TID.
         * return the starting frame's sequence number in start_seq_nums.
         * If aggregation can not be started on a certain TID return error,
         * else return success */
        int (*ht_tx_agg_start)(struct ieee80211_hw *hw, const u8 *ra, u16 tid,
                                        u16 *start_seq_num);

        /* stop Tx aggregation for a certain DA/TID.
         * If aggregation can not be stopped on a certain TID return error,
         * else return success. generator field gives the HW an indication who
         * requests to stop the aggregation - recipient (0) or initiator (1)
         */
        int (*ht_tx_agg_stop)(struct ieee80211_hw *hw, const u8 *ra, u16 tid);

        /* move to Rx aggregation for a certain DA/TID.
         * If aggregation can not be started on a certain TID return error,
         * else return success */
        int (*ht_rx_agg_start)(struct ieee80211_hw *hw, const u8 *ra, u16 tid,
                                u16 start_seq_num);

        /* stop Rx aggregation for a certain DA/TID.
         * If aggregation can not be stopped on a certain TID return error,
         * else return success. generator field gives the HW an indication who
         * requests to stop the aggregation - recipient (0) or initiator (1)
        */
        int (*ht_rx_agg_stop)(struct ieee80211_hw *hw, const u8 *ra, u16 tid,
                                int generator);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Ziegler | 1 Oct 11:14
Picon
Favicon

Re: 802.11n drivers

Dear all,

thanks for your fast responses.

Dear Johannes,

Perhaps we will get Hardware with the Broadcom chipset in the near
future. I doesn't believe that we can provide you with some kind of
hardware.

But when you are interested, we can cooperate and work together to
implement the 802.11n feature for Broadcom chipsets.

Patrick

Johannes Berg schrieb:
> On Fri, 2007-09-28 at 14:47 +0200, Patrick Ziegler wrote:
> 
>> we are working with new 802.11n Hardware. Is there a driver for some
>> kinds of Hardware yet?
> 
> Intel has a driver for their 4965 chipset and reverse engineering/driver
> projects for the airgo chipset are in progress.
> 
>>  Especially for Broadcom chipsets ( bcm2055 ) so
>> called "Intensi-fi" ?
> 
> No, we haven't done that yet. "2055" is the Broadcom 802.11n radio chip,
> the actual device is still identified as bcm43xx. I'm interested in
> doing the necessary reverse engineering but I don't currently have any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus Better | 1 Oct 12:18
Picon
Gravatar

rt2500pci 2.0.9 not working

I just tried the rt2500pci driver version 2.0.9 from the wireless-2.6 tree.
It does not work. There is no connection, and "iwlist scan" produces no
scan results.

I'm successfully using version 2.0.7 from wireless-dev (2.6.23-rc3 i386) on
this LG laptop.

Marcus
Permalink | Reply | 30 comments |
headers
Dan Williams | 1 Oct 16:06
Picon
Favicon

Re: userspace mlme configuration (was: Kernelspace --> Userspace MLME move and related items)

On Sat, 2007-09-29 at 14:27 +0200, Johannes Berg wrote:
> Ok, here are my thoughts on why alternative one is best. To recap, these
> are the alternatives I see when configuring the userspace MLME (copied
> from the wiki as I just wrote it there):
> 
>   Userspace MLME configuration (alternative 1)
>                    nl80211                     nl80211
>     { nm | iw } -------------> { cfg80211 } -------------> { umlme }
> 
>   Userspace MLME configuration (alternative 2)
>                    nl80211
>     { nm | iw } -------------> { umlme }
> 
>   Userspace MLME configuration (alternative 3)
>                   socket (*)
>     { nm | iw } -------------> { umlme }
> 
> 
> Currently, we have alternative three being used by nm and wpa_cli to
> configure wpa_supplicant via the control socket.

Note that NM 0.7 drives wpa_supplicant over D-Bus.  It doesn't use the
wpa_supplicant control socket any more.  It was ugly.

> As I said before, I favour alternative one, for the following reasons:
> 
> 1) it is transparent
> 
> Alternative one means that the userspace tools do not need to know
> whether a userspace MLME is used or not. It is completely transparent,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 1 Oct 16:18
Picon
Favicon

Re: wext 64-bit: network manager and wpa_supplicant

On Thu, 2007-09-20 at 13:56 -0700, Jean Tourrilhes wrote:
> On Thu, Sep 20, 2007 at 07:01:09PM +0200, Johannes Berg wrote:
> > 
> > > 	Then, I modified NetworkManaged to use libiw for scan
> > > parsing. The idea was to simplify NetworkManager and fix the 32-64 bit
> > > bug, plus a few other potential gotchas. The first version of
> > > NetworkManager to include that fix is 0.6.5. But, I've just realised
> > > that I did not convert event parsing, which could be an issue, I'll
> > > try to work on that.
> > > 	Note that the other big issue is that, if wpa_supplicant is
> > > present, NetworkManager will request the scan from it, and won't use
> > > its internal code, so all those fixes are useless. Maybe there should
> > > be a control to force NetworkManager to use its own scan code when
> > > needed.
> > 
> > Does NM always use wpa_supplicant even in 0.6.5? I thought only later
> > versions deferred everything to it.
> 
> 	That was my assumption as well, and the reason I spent time
> doing my patch. However, after your bug report, and before replying to
> you, I went back looking at the code, to verify.
> 	Well, as it happens, 0.6.5 uses wpa_supplicant for the scan if
> it's available (more below).

This is mainly to ensure that wpa_supplicant and NM scan in a
coordinated manner.  Otherwise you get into a situation where
wpa_supplicant scans, and NM's scan timer happens to fall right after
wpa_supplicant's, and the driver gets two back-to-back scan requests
(maybe the second one even overlaps the first).  Makes drivers confused.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jean Tourrilhes | 1 Oct 20:18
Picon
Favicon

Re: wext 64-bit: network manager and wpa_supplicant

On Mon, Oct 01, 2007 at 10:18:10AM -0400, Dan Williams wrote:
> On Thu, 2007-09-20 at 13:56 -0700, Jean Tourrilhes wrote:
> > 
> > 	Well, as it happens, 0.6.5 uses wpa_supplicant for the scan if
> > it's available (more below).
> 
> This is mainly to ensure that wpa_supplicant and NM scan in a
> coordinated manner.  Otherwise you get into a situation where
> wpa_supplicant scans, and NM's scan timer happens to fall right after
> wpa_supplicant's, and the driver gets two back-to-back scan requests
> (maybe the second one even overlaps the first).  Makes drivers confused.

	Yes, I fully agree with this decision, it look to me the right
way to do it.

> > 	I'm currently stuck because I don't have a box handy to try
> > NetworkManager on, most of my boxes are without all the Gnome
> > overhead. I'll try to fix that, but it may take a few days.
> > 	Meanwhile, I made a few patch just for you for NetworkManager
> > 0.6.5. I could not even try to compile it (./configure dependancy), so
> > beware.
> 
> I think you already did the patch and sent it, and it was committed on
> March 2, 2007 to NM CVS.  Unfortunately, I don't think we've cut a
> release of NM "stable" (which would be 0.6.5) for a long time, which is
> probably quite overdue.  Most distros should be shipping a 0.6.5
> snapshot at least.

	The patch last march was for the "scanning" code. The new
patch is for the "event" code. Yes, last march, I totally forgot about
(Continue reading)

Permalink | Reply | 0 comments |
headers
John W. Linville | 1 Oct 22:12
Favicon

mac80211 multiqueue

On Mon, Sep 10, 2007 at 10:09:32AM +0800, Zhu Yi wrote:
> On Fri, 2007-09-07 at 15:40 +0200, Johannes Berg wrote:

> > > BTW， the whole 802.11 qdisc hack will be removed with
> > > the multiqueue supported in .24.  
> > 
> > Yeah, is anybody working on that? I have to admit I didn't look into
> > that yet.
> 
> If nobody will work on that, we Intel will do. I remembered Tomas
> promised John in this OLS ;)

Indeed he did...Tomas, any progress on this?

John
--

-- 
John W. Linville
linville@...
Permalink | Reply | 1 comment |
headers
John W. Linville | 1 Oct 22:47
Favicon

Re: Belkin Wireless G USB

On Fri, Sep 28, 2007 at 03:10:34PM -0500, John Pierce wrote:

> This is the output of dmesg immediately after inserting the usb adapter.
> 
> usb 2-2: new high speed USB device using ehci_hcd and address 7
> usb 2-2: configuration #1 chosen from 1 choice
> usb 2-2: reset high speed USB device using ehci_hcd and address 7
> wmaster0: Failed to select rate control algorithm
> wmaster0: Failed to initialize rate control algorithm
> usb 2-2: reset high speed USB device using ehci_hcd and address 7
> zd1211rw_mac80211: probe of 2-2:1.0 failed with error -2
> usbcore: registered new interface driver zd1211rw_mac80211

You may want to move this to bugzilla.redhat.com.

As a first check, did you install the zd1211-firmware package?

John
--

-- 
John W. Linville
linville@...
Permalink | Reply | 1 comment |

Gmane