* Re: Changing the way we handle region codes on Linux (public thread)
From: John W. Linville @ 2009-11-06 18:38 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bob Copeland, linux-wireless, Vivek Natarajan, Vivek Natarajan,
Jeffrey Baker, David Quan, Michael Green
In-Reply-To: <43e72e890911060945s3b00e056u1efe483bd88ebd30@mail.gmail.com>
On Fri, Nov 06, 2009 at 09:45:29AM -0800, Luis R. Rodriguez wrote:
> On Fri, Nov 6, 2009 at 9:29 AM, Bob Copeland <me@bobcopeland.com> wrote:
> > On Fri, Nov 6, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> >
> >> I think that sums it up.
> >
> > I personally still like the idea of pushing the vendor-specific
> > codes out to user space and having psuedo-country codes for
> > those (e.g. "ATH_37"). Then the driver doesn't need all of the
> > static rules loaded all the time and it would drop a lot of
> > policy code from the driver. CRDA could be enhanced to load
> > multiple databases, one for pure iso-3166 codes, one with
> > Atheros codes, one with Intel, etc.
<snip>
> But with that said -- I think the region-code scheme is overly complex
> and am not sure if aiding it is something we should focus energy and
> resources on. It would seem better to me to focus on more cleaner
> solutions and leave that old stuff as legacy solutions.
That's the thing about "legacy" stuff -- it doesn't go away just from
ignoring it!
FWIW, I think Bob's suggestion makes a lot of sense.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Prism54/p54pci
From: James Grossmann @ 2009-11-06 18:45 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <200911061848.21681.chunkeey@googlemail.com>
Here's the iwconfig:
wlan1 IEEE 802.11bg ESSID:"newton"
Mode:Managed Frequency:2.462 GHz Access Point: 00:xx:xx:xx:xx:xx
Bit Rate=48 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=50/70 Signal level=-60 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
I was unable to run the iperf as the client on the laptop (it hard
locked the computer twice), I ran it as server and received the
following at a fair distance from the router (a couple of rooms, same
as the iwconfig above)
Client connecting to 192.168.1.3, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.5 port 47866 connected with 192.168.1.3 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.4 sec 14.6 MBytes 11.7 Mbits/sec
Same test across the room from the router:
iperf -c 192.168.1.3
------------------------------------------------------------
Client connecting to 192.168.1.3, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.5 port 47867 connected with 192.168.1.3 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 21.4 MBytes 17.9 Mbits/sec
wlan1 IEEE 802.11bg ESSID:"newton"
Mode:Managed Frequency:2.462 GHz Access Point: 00:xx:xx:xx:xx:xx
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=70/70 Signal level=-37 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Here's a little bit more I've been getting in my dmesg:
[ 91.453279] wlan1: deauthenticating from 00:xx:xx:xx:xx:xx by local
choice (reason=3)
[ 91.453421] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
[ 91.457825] wlan1: direct probe responded
[ 91.457839] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx (try 1)
[ 91.462748] wlan1: authenticated
[ 91.462808] wlan1: associate with AP 00:xx:xx:xx:xx:xx (try 1)
[ 91.465574] wlan1: RX AssocResp from 00:xx:xx:xx:xx:xx (capab=0x401
status=0 aid=2)
[ 91.465584] wlan1: associated
[ 91.467208] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 101.500094] wlan1: no IPv6 routers present
[ 101.893294] ondemand governor failed, too long transition latency
of HW, fallback to performance governor
[ 773.648180] wlan1: deauthenticated from 00:xx:xx:xx:xx:xx (Reason: 7)
[ 773.649900] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
[ 773.654069] wlan1: direct probe responded
[ 773.654082] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx (try 1)
[ 773.655939] wlan1: deauthenticated from 00:xx:xx:xx:xx:xx (Reason: 7)
On Fri, Nov 6, 2009 at 11:48 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Friday 06 November 2009 18:00:54 James Grossmann wrote:
>> It connects up with the patch!
>> I'll attach a dmesg for any info you might be able to glean from that.
>> THANKS!
>
> it's a start, but there are some serious implications.
>
> but first: what is your signal (dBm) reading (iwconfig / iw dev wlanX info)?
>
> I'm asking this because your device is only fine-tunable for
> channel 1, 7, 13 & 14 with the current data points.
>
> some performance figures would be nice as well.
> e.g.: iperf (tcp) should be > 18Mbit/s,
> if you are close & free line of sight
>
> second: what should we do about these devices?
>
> Surely, the best thing would be to simply reprogram the eeprom,
> but this (being complicated work) requires soldering skills/tools,
> a steady hand and enough boredom. Therefor this is likely the least
> ideal option to put into the WIKI @ wireless.kernel.org .
> Any suitable ideas?
>
> Regards,
> Chr
>
> ---
>> [ 5593.622225] cfg80211: Calling CRDA to update world regulatory
>> domain
>> [ 5593.756965] p54pci 0000:03:00.0: PCI INT A -> Link[LNKA] -> GSI 11
>> (level, low) -> IRQ 11
>> [ 5593.757087] p54pci 0000:03:00.0: firmware: requesting isl3886pci
>> [ 5593.799682] cfg80211: World regulatory domain updated:
>> [ 5593.799693] (start_freq - end_freq @ bandwidth),
>> (max_antenna_gain, max_eirp)
>> [ 5593.799701] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi,
>> 2000 mBm)
>> [ 5593.799708] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi,
>> 2000 mBm)
>> [ 5593.799714] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi,
>> 2000 mBm)
>> [ 5593.799721] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> [ 5593.799728] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> [ 5593.826106] phy0: p54 detected a LM86 firmware
>> [ 5593.826115] p54: rx_mtu reduced from 3240 to 2376
>> [ 5593.826121] phy0: FW rev 2.13.12.0 - Softmac protocol 5.9
>> [ 5593.826127] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
>> [ 5593.943095] phy0: hwaddr 00:xx:xx:xx:xx:xx, MAC:isl3880 RF:Frisbee
>>
>> [ 5593.943532] phy0: Selected rate control algorithm 'minstrel'
>> [ 5593.945386] Registered led device: p54-phy0::assoc
>> [ 5593.945426] Registered led device: p54-phy0::tx
>> [ 5593.945466] Registered led device: p54-phy0::rx
>> [ 5593.945507] Registered led device: p54-phy0::radio
>> [ 5593.945521] p54pci 0000:03:00.0: is registered as 'phy0'
>> [ 5593.973148] udev: renamed network interface wlan0 to wlan1
>> [ 5594.105670] ADDRCONF(NETDEV_UP): wlan1: link is not ready
>> [ 5601.380939] wlan1: deauthenticating from 00:xx:xx:xx:xx:xx by local
>> choice (reason=3)
>> [ 5601.381046] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
>> [ 5601.385723] wlan1: direct probe responded
>> [ 5601.385738] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx (try 1)
>> [ 5601.387961] wlan1: authenticated
>> [ 5601.388049] wlan1: associate with AP 00:xx:xx:xx:xx:xx (try 1)
>> [ 5601.390237] wlan1: RX AssocResp from 00:xx:xx:xx:xx:xx (capab=0x401
>> status=0 aid=2)
>> [ 5601.390246] wlan1: associated
>> [ 5601.391891] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
>> [ 5612.024163] wlan1: no IPv6 routers present
>>
>
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: John W. Linville @ 2009-11-06 18:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, Pavel Machek, Ingo Molnar, linux-wireless,
linux-kernel, netdev, Randy Dunlap, Luis Correia, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911061930.13069.bzolnier@gmail.com>
On Fri, Nov 06, 2009 at 07:30:13PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Friday 06 November 2009 18:58:56 Ivo van Doorn wrote:
> > the merged for those drivers after the asurance that it was only merged
> > to please the users so developers could focus on the rt2x00 version of
> > the driver.
>
> Could somebody please explain me (in the public or in the private) what is
> the reason behind whole affair about staging drivers because all the time
> I feel like I'm missing some important detail here.
I'm not 100% sure what you are asking, but I think you want to know
the basis for general objections from the people that hang-out on
linux-wireless and/or the rt2x00 team specifically?
I don't think anyone[1] has overwhelming objections to drivers in
staging for devices that have no other driver available. The main
objection is that drivers/staging steals users and (and often
developers) from the non-staging drivers, reducing the amount of
testing and development they get. In the effort to help some users,
drivers/staging effectively prolongs the amount of time those users
have to go without properly supported drivers. Much worse, none of
the wireless drivers in drivers/staging seem to have generated an
actual mergeable[2] wireless driver.
Further, the wireless drivers in drivers/staging are completely
isolated from the wireless infrastructure developments we've been
making over the past few years. The longer they live, the longer
wireless extensions will linger, the longer custom rfkill solutions
persist, and the longer we have multiple 802.11 stack implementations.
Finally, bug reports from drivers/staging are an unwelcome distraction
in bugzilla and the wireless mailing lists. Not only do those drivers
generate (often wierd) bugs, we get the privilege of looking like
jerks for refusing to deal with those reports even though we objected
to including the drivers in the first place.
It is little wonder to me why the linux-wireless folks oppose
drivers/staging...
Hth!
John
[1] Actually, I _know_ there are people who object to all of
drivers/staging, but few of those are actively and vigorously objecting
to it.
[2] A mergeable driver should respect and/or utilize existing wireless
infrastructure rather than duplicating it, as well as meeting general
standards of maintainability. Preferably it would have someone to
stand behind it as a maintainer as well.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: b43: firmware loading problem and sleeping BUG
From: Michael Buesch @ 2009-11-06 19:08 UTC (permalink / raw)
To: Martin Fuzzey; +Cc: linux-wireless
In-Reply-To: <ba4215e10911061027t413d2c34g8ad66a7982f7c43c@mail.gmail.com>
On Friday 06 November 2009 19:27:17 Martin Fuzzey wrote:
> > I think this is easy to fix, because we can replace the spinlock by a mutex, as
> > the b43 driver (which is the only user of the code) always allows sleeping now.
> > I'll send a patch for testing soon.
> >
> Great - happy to test it.
There you go. Note that I did not test it, as trying to use my pcmcia card throws
a hell of a lot oopses at me and the firmware finally force-resets the hardware
for some reason. This needs some debugging first...
Index: wireless-testing/drivers/ssb/main.c
===================================================================
--- wireless-testing.orig/drivers/ssb/main.c 2009-10-09 19:50:16.000000000 +0200
+++ wireless-testing/drivers/ssb/main.c 2009-11-06 19:47:18.000000000 +0100
@@ -740,7 +740,7 @@ static int ssb_bus_register(struct ssb_b
{
int err;
- spin_lock_init(&bus->bar_lock);
+ mutex_init(&bus->register_mutex);
INIT_LIST_HEAD(&bus->list);
#ifdef CONFIG_SSB_EMBEDDED
spin_lock_init(&bus->gpio_lock);
Index: wireless-testing/drivers/ssb/pcmcia.c
===================================================================
--- wireless-testing.orig/drivers/ssb/pcmcia.c 2009-07-28 22:53:08.000000000 +0200
+++ wireless-testing/drivers/ssb/pcmcia.c 2009-11-06 19:35:59.000000000 +0100
@@ -238,15 +238,14 @@ static int select_core_and_segment(struc
static u8 ssb_pcmcia_read8(struct ssb_device *dev, u16 offset)
{
struct ssb_bus *bus = dev->bus;
- unsigned long flags;
int err;
u8 value = 0xFF;
- spin_lock_irqsave(&bus->bar_lock, flags);
+ mutex_lock(&bus->register_mutex);
err = select_core_and_segment(dev, &offset);
if (likely(!err))
value = readb(bus->mmio + offset);
- spin_unlock_irqrestore(&bus->bar_lock, flags);
+ mutex_unlock(&bus->register_mutex);
return value;
}
@@ -254,15 +253,14 @@ static u8 ssb_pcmcia_read8(struct ssb_de
static u16 ssb_pcmcia_read16(struct ssb_device *dev, u16 offset)
{
struct ssb_bus *bus = dev->bus;
- unsigned long flags;
int err;
u16 value = 0xFFFF;
- spin_lock_irqsave(&bus->bar_lock, flags);
+ mutex_lock(&bus->register_mutex);
err = select_core_and_segment(dev, &offset);
if (likely(!err))
value = readw(bus->mmio + offset);
- spin_unlock_irqrestore(&bus->bar_lock, flags);
+ mutex_unlock(&bus->register_mutex);
return value;
}
@@ -270,17 +268,16 @@ static u16 ssb_pcmcia_read16(struct ssb_
static u32 ssb_pcmcia_read32(struct ssb_device *dev, u16 offset)
{
struct ssb_bus *bus = dev->bus;
- unsigned long flags;
int err;
u32 lo = 0xFFFFFFFF, hi = 0xFFFFFFFF;
- spin_lock_irqsave(&bus->bar_lock, flags);
+ mutex_lock(&bus->register_mutex);
err = select_core_and_segment(dev, &offset);
if (likely(!err)) {
lo = readw(bus->mmio + offset);
hi = readw(bus->mmio + offset + 2);
}
- spin_unlock_irqrestore(&bus->bar_lock, flags);
+ mutex_unlock(&bus->register_mutex);
return (lo | (hi << 16));
}
@@ -290,11 +287,10 @@ static void ssb_pcmcia_block_read(struct
size_t count, u16 offset, u8 reg_width)
{
struct ssb_bus *bus = dev->bus;
- unsigned long flags;
void __iomem *addr = bus->mmio + offset;
int err;
- spin_lock_irqsave(&bus->bar_lock, flags);
+ mutex_lock(&bus->register_mutex);
err = select_core_and_segment(dev, &offset);
if (unlikely(err)) {
memset(buffer, 0xFF, count);
@@ -339,52 +335,49 @@ static void ssb_pcmcia_block_read(struct
SSB_WARN_ON(1);
}
unlock:
- spin_unlock_irqrestore(&bus->bar_lock, flags);
+ mutex_unlock(&bus->register_mutex);
}
#endif /* CONFIG_SSB_BLOCKIO */
static void ssb_pcmcia_write8(struct ssb_device *dev, u16 offset, u8 value)
{
struct ssb_bus *bus = dev->bus;
- unsigned long flags;
int err;
- spin_lock_irqsave(&bus->bar_lock, flags);
+ mutex_lock(&bus->register_mutex);
err = select_core_and_segment(dev, &offset);
if (likely(!err))
writeb(value, bus->mmio + offset);
mmiowb();
- spin_unlock_irqrestore(&bus->bar_lock, flags);
+ mutex_unlock(&bus->register_mutex);
}
static void ssb_pcmcia_write16(struct ssb_device *dev, u16 offset, u16 value)
{
struct ssb_bus *bus = dev->bus;
- unsigned long flags;
int err;
- spin_lock_irqsave(&bus->bar_lock, flags);
+ mutex_lock(&bus->register_mutex);
err = select_core_and_segment(dev, &offset);
if (likely(!err))
writew(value, bus->mmio + offset);
mmiowb();
- spin_unlock_irqrestore(&bus->bar_lock, flags);
+ mutex_unlock(&bus->register_mutex);
}
static void ssb_pcmcia_write32(struct ssb_device *dev, u16 offset, u32 value)
{
struct ssb_bus *bus = dev->bus;
- unsigned long flags;
int err;
- spin_lock_irqsave(&bus->bar_lock, flags);
+ mutex_lock(&bus->register_mutex);
err = select_core_and_segment(dev, &offset);
if (likely(!err)) {
writew((value & 0x0000FFFF), bus->mmio + offset);
writew(((value & 0xFFFF0000) >> 16), bus->mmio + offset + 2);
}
mmiowb();
- spin_unlock_irqrestore(&bus->bar_lock, flags);
+ mutex_unlock(&bus->register_mutex);
}
#ifdef CONFIG_SSB_BLOCKIO
@@ -392,11 +385,10 @@ static void ssb_pcmcia_block_write(struc
size_t count, u16 offset, u8 reg_width)
{
struct ssb_bus *bus = dev->bus;
- unsigned long flags;
void __iomem *addr = bus->mmio + offset;
int err;
- spin_lock_irqsave(&bus->bar_lock, flags);
+ mutex_lock(&bus->register_mutex);
err = select_core_and_segment(dev, &offset);
if (unlikely(err))
goto unlock;
@@ -440,7 +432,7 @@ static void ssb_pcmcia_block_write(struc
}
unlock:
mmiowb();
- spin_unlock_irqrestore(&bus->bar_lock, flags);
+ mutex_unlock(&bus->register_mutex);
}
#endif /* CONFIG_SSB_BLOCKIO */
Index: wireless-testing/include/linux/ssb/ssb.h
===================================================================
--- wireless-testing.orig/include/linux/ssb/ssb.h 2009-11-01 13:58:49.000000000 +0100
+++ wireless-testing/include/linux/ssb/ssb.h 2009-11-06 19:32:32.000000000 +0100
@@ -278,9 +278,8 @@ struct ssb_bus {
/* Current SSB base address window for SDIO. */
u32 sdio_sbaddr;
};
- /* Lock for core and segment switching.
- * On PCMCIA-host busses this is used to protect the whole MMIO access. */
- spinlock_t bar_lock;
+ /* Mutex to enforce one hardware register read/write is an atomic operation. */
+ struct mutex register_mutex;
/* The host-bus this backplane is running on. */
enum ssb_bustype bustype;
Index: wireless-testing/drivers/ssb/pci.c
===================================================================
--- wireless-testing.orig/drivers/ssb/pci.c 2009-10-09 19:50:16.000000000 +0200
+++ wireless-testing/drivers/ssb/pci.c 2009-11-06 20:04:11.000000000 +0100
@@ -63,7 +63,6 @@ int ssb_pci_switch_core(struct ssb_bus *
struct ssb_device *dev)
{
int err;
- unsigned long flags;
#if SSB_VERBOSE_PCICORESWITCH_DEBUG
ssb_printk(KERN_INFO PFX
@@ -72,11 +71,9 @@ int ssb_pci_switch_core(struct ssb_bus *
dev->core_index);
#endif
- spin_lock_irqsave(&bus->bar_lock, flags);
err = ssb_pci_switch_coreidx(bus, dev->core_index);
if (!err)
bus->mapped_device = dev;
- spin_unlock_irqrestore(&bus->bar_lock, flags);
return err;
}
--
Greetings, Michael.
^ permalink raw reply
* Re: Prism54/p54pci
From: Christian Lamparter @ 2009-11-06 19:14 UTC (permalink / raw)
To: James Grossmann; +Cc: linux-wireless
In-Reply-To: <167ae39b0911061045i63b1650qa1573aa2427f9812@mail.gmail.com>
On Friday 06 November 2009 19:45:53 James Grossmann wrote:
> Here's the iwconfig:
> wlan1 IEEE 802.11bg ESSID:"newton"
> Mode:Managed Frequency:2.462 GHz Access Point: 00:xx:xx:xx:xx:xx
> Bit Rate=48 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Power Management:off
> Link Quality=50/70 Signal level=-60 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> I was unable to run the iperf as the client on the laptop
> (it hard locked the computer twice),
huu, that's really bad. especially, since a new release is around the corner.
Do you think you can catch the oops/bug report?
(switch to virtual terminal Alt-Ctrl-F1 and start iperf -c there)
> I ran it as server and received the
> following at a fair distance from the router (a couple of rooms, same
> as the iwconfig above)
> Client connecting to 192.168.1.3, TCP port 5001
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [ 3] local 192.168.1.5 port 47866 connected with 192.168.1.3 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0-10.4 sec 14.6 MBytes 11.7 Mbits/sec
>
> Same test across the room from the router:
> iperf -c 192.168.1.3
> ------------------------------------------------------------
> Client connecting to 192.168.1.3, TCP port 5001
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [ 3] local 192.168.1.5 port 47867 connected with 192.168.1.3 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0-10.0 sec 21.4 MBytes 17.9 Mbits/sec
>
> wlan1 IEEE 802.11bg ESSID:"newton"
> Mode:Managed Frequency:2.462 GHz Access Point: 00:xx:xx:xx:xx:xx
> Bit Rate=54 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Power Management:off
> Link Quality=70/70 Signal level=-37 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> Here's a little bit more I've been getting in my dmesg:
> [ 91.453279] wlan1: deauthenticating from 00:xx:xx:xx:xx:xx by local choice (reason=3)
> [ 91.453421] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
> [ 91.457825] wlan1: direct probe responded
> [ 91.457839] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx (try 1)
> [ 91.462748] wlan1: authenticated
> [ 91.462808] wlan1: associate with AP 00:xx:xx:xx:xx:xx (try 1)
> [ 91.465574] wlan1: RX AssocResp from 00:xx:xx:xx:xx:xx (capab=0x401
> status=0 aid=2)
> [ 91.465584] wlan1: associated
> [ 91.467208] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
> [ 101.500094] wlan1: no IPv6 routers present
> [ 101.893294] ondemand governor failed, too long transition latency
> of HW, fallback to performance governor
> [ 773.648180] wlan1: deauthenticated from 00:xx:xx:xx:xx:xx (Reason: 7)
> [ 773.649900] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
> [ 773.654069] wlan1: direct probe responded
> [ 773.654082] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx (try 1)
> [ 773.655939] wlan1: deauthenticated from 00:xx:xx:xx:xx:xx (Reason: 7)
Reason 7 => Class 3 (usually data frames) frame from non-assoc station.
Either, your STA timed out (due to lack of traffic?) or the AP lost
the connection state for some strange reason (reset?).
Regards,
Chr
^ permalink raw reply
* [PATCH] wireless-regdb: add Aruba (AW)
From: Luis R. Rodriguez @ 2009-11-06 19:14 UTC (permalink / raw)
To: linville
Cc: linux-wireless, Luis R. Rodriguez, Michael Green, Vivek Natarajan
We were unable to find published rules for Aruba
for regulatory purposes but given that it falls under
the same european region we have mapped Aruba to the same
region as other european countries and give it the same
rules. A device was tested for ETSI certification with
these rules and passed so I think this is a best due dillegence
as we can do to test regulatory rules for Aruba.
Reported-by: Jeffrey Baker <jwbaker@gmail.com>
Cc: Michael Green <Michael.Green@atheros.com>
Cc: Vivek Natarajan <Vivek.Natarajan@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
db.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/db.txt b/db.txt
index c71b35b..a3cd6be 100644
--- a/db.txt
+++ b/db.txt
@@ -46,6 +46,12 @@ country AU:
(5250 - 5330 @ 40), (3, 23), DFS
(5735 - 5835 @ 40), (3, 30)
+country AW:
+ (2402 - 2482 @ 40), (N/A, 20)
+ (5170 - 5250 @ 40), (N/A, 20)
+ (5250 - 5330 @ 40), (N/A, 20), DFS
+ (5490 - 5710 @ 40), (N/A, 27), DFS
+
country AZ:
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 40), (N/A, 18)
--
1.6.5.2.143.g8cc62
^ permalink raw reply related
* Re: Changing the way we handle region codes on Linux (public thread)
From: Luis R. Rodriguez @ 2009-11-06 19:20 UTC (permalink / raw)
To: John W. Linville
Cc: Bob Copeland, linux-wireless, Vivek Natarajan, Vivek Natarajan,
Jeffrey Baker, David Quan, Michael Green
In-Reply-To: <20091106183833.GC2782@tuxdriver.com>
On Fri, Nov 6, 2009 at 10:38 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Fri, Nov 06, 2009 at 09:45:29AM -0800, Luis R. Rodriguez wrote:
>> On Fri, Nov 6, 2009 at 9:29 AM, Bob Copeland <me@bobcopeland.com> wrote:
>> > On Fri, Nov 6, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> >
>> >> I think that sums it up.
>> >
>> > I personally still like the idea of pushing the vendor-specific
>> > codes out to user space and having psuedo-country codes for
>> > those (e.g. "ATH_37"). Then the driver doesn't need all of the
>> > static rules loaded all the time and it would drop a lot of
>> > policy code from the driver. CRDA could be enhanced to load
>> > multiple databases, one for pure iso-3166 codes, one with
>> > Atheros codes, one with Intel, etc.
>
> <snip>
>
>> But with that said -- I think the region-code scheme is overly complex
>> and am not sure if aiding it is something we should focus energy and
>> resources on. It would seem better to me to focus on more cleaner
>> solutions and leave that old stuff as legacy solutions.
>
> That's the thing about "legacy" stuff -- it doesn't go away just from
> ignoring it!
True.
> FWIW, I think Bob's suggestion makes a lot of sense.
Patches welcomed then :)
Luis
^ permalink raw reply
* Re: Changing the way we handle region codes on Linux (public thread)
From: Luis R. Rodriguez @ 2009-11-06 19:26 UTC (permalink / raw)
To: John W. Linville
Cc: Bob Copeland, linux-wireless, Vivek Natarajan, Vivek Natarajan,
Jeffrey Baker, David Quan, Michael Green
In-Reply-To: <43e72e890911061120mc3f66cbl272adc273a39cb0c@mail.gmail.com>
On Fri, Nov 6, 2009 at 11:20 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 10:38 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
>>
>> FWIW, I think Bob's suggestion makes a lot of sense.
>
> Patches welcomed then :)
So this could consist probably of adding one more environment variable
to the passed COUNTRY one that the kernel passes before calling crda,
a group I guess, andif the group is passed the crda can read
/path/grop-regulatory.bin where group could be ATHR for example.
BTW -- the region codes are already present on db.txt -- so the only
thing that group thing could do is allow us to move the 12 regulatory
domains to userspace and I'm not sure if this is someone's time,
specially since I managed to squeeze the 12 world regulatory domains
to 5 structures, the slight modifications between a few are handled
internally on ath.ko through the reg notifier, see:
static void ath_reg_apply_world_flags(struct wiphy *wiphy,
enum nl80211_reg_initiator initiator,
struct ath_regulatory *reg)
{
switch (reg->regpair->regDmnEnum) {
case 0x60:
case 0x63:
case 0x66:
case 0x67:
ath_reg_apply_beaconing_flags(wiphy, initiator);
break;
case 0x68:
ath_reg_apply_beaconing_flags(wiphy, initiator);
ath_reg_apply_active_scan_flags(wiphy, initiator);
break;
}
return;
}
Luis
^ permalink raw reply
* Re: Changing the way we handle region codes on Linux (public thread)
From: John W. Linville @ 2009-11-06 19:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bob Copeland, linux-wireless, Vivek Natarajan, Vivek Natarajan,
Jeffrey Baker, David Quan, Michael Green
In-Reply-To: <43e72e890911061120mc3f66cbl272adc273a39cb0c@mail.gmail.com>
On Fri, Nov 06, 2009 at 11:20:34AM -0800, Luis R. Rodriguez wrote:
> On Fri, Nov 6, 2009 at 10:38 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Fri, Nov 06, 2009 at 09:45:29AM -0800, Luis R. Rodriguez wrote:
> >> On Fri, Nov 6, 2009 at 9:29 AM, Bob Copeland <me@bobcopeland.com> wrote:
> >> > On Fri, Nov 6, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> >> >
> >> >> I think that sums it up.
> >> >
> >> > I personally still like the idea of pushing the vendor-specific
> >> > codes out to user space and having psuedo-country codes for
> >> > those (e.g. "ATH_37"). Then the driver doesn't need all of the
> >> > static rules loaded all the time and it would drop a lot of
> >> > policy code from the driver. CRDA could be enhanced to load
> >> > multiple databases, one for pure iso-3166 codes, one with
> >> > Atheros codes, one with Intel, etc.
> >
> > <snip>
> >
> >> But with that said -- I think the region-code scheme is overly complex
> >> and am not sure if aiding it is something we should focus energy and
> >> resources on. It would seem better to me to focus on more cleaner
> >> solutions and leave that old stuff as legacy solutions.
> >
> > That's the thing about "legacy" stuff -- it doesn't go away just from
> > ignoring it!
>
> True.
>
> > FWIW, I think Bob's suggestion makes a lot of sense.
>
> Patches welcomed then :)
Haha...OK, I'll put it on my list... Lurkers are welcome to beat me to it!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Prism54/p54pci
From: James Grossmann @ 2009-11-06 19:37 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <200911062014.19363.chunkeey@googlemail.com>
Doing it from the console doesn't seem to give a kernel oops... it
just locks up the computer such that I can't even change the caps lock
status. It starts the connection, and then the activity light on the
card goes on and the computer is locked up.
With regard to the losing connection/timing out, I'm seeing that a
fair amount, when I have data transferring (watching an active ssh
connection, or streaming audio), and especially when I'm not doing
anything...
Thanks,
James
On Fri, Nov 6, 2009 at 1:14 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Friday 06 November 2009 19:45:53 James Grossmann wrote:
>> Here's the iwconfig:
>> wlan1 IEEE 802.11bg ESSID:"newton"
>> Mode:Managed Frequency:2.462 GHz Access Point: 00:xx:xx:xx:xx:xx
>> Bit Rate=48 Mb/s Tx-Power=20 dBm
>> Retry long limit:7 RTS thr:off Fragment thr:off
>> Power Management:off
>> Link Quality=50/70 Signal level=-60 dBm
>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>>
>> I was unable to run the iperf as the client on the laptop
>> (it hard locked the computer twice),
> huu, that's really bad. especially, since a new release is around the corner.
>
> Do you think you can catch the oops/bug report?
> (switch to virtual terminal Alt-Ctrl-F1 and start iperf -c there)
>
>> I ran it as server and received the
>> following at a fair distance from the router (a couple of rooms, same
>> as the iwconfig above)
>> Client connecting to 192.168.1.3, TCP port 5001
>> TCP window size: 16.0 KByte (default)
>> ------------------------------------------------------------
>> [ 3] local 192.168.1.5 port 47866 connected with 192.168.1.3 port 5001
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0-10.4 sec 14.6 MBytes 11.7 Mbits/sec
>>
>> Same test across the room from the router:
>> iperf -c 192.168.1.3
>> ------------------------------------------------------------
>> Client connecting to 192.168.1.3, TCP port 5001
>> TCP window size: 16.0 KByte (default)
>> ------------------------------------------------------------
>> [ 3] local 192.168.1.5 port 47867 connected with 192.168.1.3 port 5001
>> [ ID] Interval Transfer Bandwidth
>> [ 3] 0.0-10.0 sec 21.4 MBytes 17.9 Mbits/sec
>>
>> wlan1 IEEE 802.11bg ESSID:"newton"
>> Mode:Managed Frequency:2.462 GHz Access Point: 00:xx:xx:xx:xx:xx
>> Bit Rate=54 Mb/s Tx-Power=20 dBm
>> Retry long limit:7 RTS thr:off Fragment thr:off
>> Power Management:off
>> Link Quality=70/70 Signal level=-37 dBm
>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>>
>> Here's a little bit more I've been getting in my dmesg:
>> [ 91.453279] wlan1: deauthenticating from 00:xx:xx:xx:xx:xx by local choice (reason=3)
>> [ 91.453421] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
>> [ 91.457825] wlan1: direct probe responded
>> [ 91.457839] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx (try 1)
>> [ 91.462748] wlan1: authenticated
>> [ 91.462808] wlan1: associate with AP 00:xx:xx:xx:xx:xx (try 1)
>> [ 91.465574] wlan1: RX AssocResp from 00:xx:xx:xx:xx:xx (capab=0x401
>> status=0 aid=2)
>> [ 91.465584] wlan1: associated
>> [ 91.467208] ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
>> [ 101.500094] wlan1: no IPv6 routers present
>> [ 101.893294] ondemand governor failed, too long transition latency
>> of HW, fallback to performance governor
>
>> [ 773.648180] wlan1: deauthenticated from 00:xx:xx:xx:xx:xx (Reason: 7)
>> [ 773.649900] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
>> [ 773.654069] wlan1: direct probe responded
>> [ 773.654082] wlan1: authenticate with AP 00:xx:xx:xx:xx:xx (try 1)
>> [ 773.655939] wlan1: deauthenticated from 00:xx:xx:xx:xx:xx (Reason: 7)
>
> Reason 7 => Class 3 (usually data frames) frame from non-assoc station.
> Either, your STA timed out (due to lack of traffic?) or the AP lost
> the connection state for some strange reason (reset?).
>
> Regards,
> Chr
>
^ permalink raw reply
* Re: iwlwifi connection troubles, maybe aggregation related
From: Andrew Lutomirski @ 2009-11-06 19:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ilw
In-Reply-To: <1257327017.28469.76.camel@johannes.local>
On Wed, Nov 4, 2009 at 4:30 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2009-11-03 at 18:38 -0500, Andrew Lutomirski wrote:
>
>> iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:21:d8:49:4a:52 tid = 0
>
>> Turning on or off power management and fiddling with
>> no_sleep_autoadjust makes no difference. Setting tx_agg_tid_enable to
>> zero in debugfs while the connection was working seemed to make it a
>> little more reliable (it lasted long enough to do "git pull" but not
>> much longer).
>>
>> After running "iw dev wlan0 disconnect" a few times, I start to get
>> errors like this:
>>
>> [18078.209635] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
>> [18078.313461] iwlagn 0000:03:00.0: No space for Tx
>> [18078.313467] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
>> enqueue_hcmd failed: -28
>> [18078.313470] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
>> [18078.522409] iwlagn 0000:03:00.0: No space for Tx
>> [18078.522414] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
>> enqueue_hcmd failed: -28
>
> Sounds like the firmware messes up ...
>
> Maybe as a first workaround you could modprobe iwlagn with
> 11n_disable=1. But I don't know at this point what the problem could be.
11n_disable50=1 seems to work. I'll reply again if it stops working.
Do the Intel folks have any ideas?
Thanks,
Andy
^ permalink raw reply
* Re: [PATCH 02/41] rt2800pci: make Kconfig help entry more helpful
From: Gertjan van Wingerde @ 2009-11-06 19:53 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-wireless, Ivo van Doorn, linux-kernel, John W. Linville
In-Reply-To: <200911061713.09133.bzolnier@gmail.com>
On 11/06/09 17:13, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 04 November 2009 19:26:16 Gertjan van Wingerde wrote:
>> On Wed, Nov 4, 2009 at 6:32 PM, Bartlomiej Zolnierkiewicz
>> <bzolnier@gmail.com> wrote:
>>> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
>>> Subject: [PATCH] rt2800pci: make Kconfig help entry more helpful
>>>
>>> Document known issues with the driver to aid distribution makers,
>>> users and developers in making informed decisions instead of wasting
>>> their time needlessly.
>>>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
>>> ---
>>> This reflects the actual state of affairs for driver in net-next tree.
>>>
>>
>> Maybe we should consider making this one depend on BROKEN, for the
>> moment at least?
>
> Sounds fine with me, would you be willing to take care of this?
>
Sure. No problem. Will produce a patch once your series has been merged.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH 10/41] rt2800pci: add rt2800_register_[read,write]() wrappers
From: Gertjan van Wingerde @ 2009-11-06 19:55 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-wireless, Ivo van Doorn, linux-kernel, John W. Linville
In-Reply-To: <200911061713.15898.bzolnier@gmail.com>
On 11/06/09 17:13, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 04 November 2009 20:16:26 Gertjan van Wingerde wrote:
>> On Wed, Nov 4, 2009 at 6:33 PM, Bartlomiej Zolnierkiewicz
>> <bzolnier@gmail.com> wrote:
>>> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
>>> Subject: [PATCH] rt2800pci: add rt2800_register_[read,write]() wrappers
>>>
>>> Part of preparations for later code unification.
>>>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
>>> ---
>>> drivers/net/wireless/rt2x00/rt2800pci.c | 479 ++++++++++++++++----------------
>>> drivers/net/wireless/rt2x00/rt2800pci.h | 21 +
>>> 2 files changed, 261 insertions(+), 239 deletions(-)
>>>
>>> Index: b/drivers/net/wireless/rt2x00/rt2800pci.c
>>> ===================================================================
>>> --- a/drivers/net/wireless/rt2x00/rt2800pci.c
>>> +++ b/drivers/net/wireless/rt2x00/rt2800pci.c
>>> @@ -57,7 +57,7 @@ MODULE_PARM_DESC(nohwcrypt, "Disable har
>>> /*
>>> * Register access.
>>> * All access to the CSR registers will go through the methods
>>> - * rt2x00pci_register_read and rt2x00pci_register_write.
>>> + * rt2800_register_read and rt2800_register_write.
>>> * BBP and RF register require indirect register access,
>>> * and use the CSR registers BBPCSR and RFCSR to achieve this.
>>> * These indirect registers work with busy bits,
>>> @@ -66,6 +66,7 @@ MODULE_PARM_DESC(nohwcrypt, "Disable har
>>> * between each attampt. When the busy bit is still set at that time,
>>> * the access attempt is considered to have failed,
>>> * and we will print an error.
>>> + * The _lock versions must be used if you already hold the csr_mutex
>>> */
>>> #define WAIT_FOR_BBP(__dev, __reg) \
>>> rt2x00pci_regbusy_read((__dev), BBP_CSR_CFG, BBP_CSR_CFG_BUSY, (__reg))
>>
>> The change to the _lock variant seems a bit odd. See below.
>>
>> <snip>
>>
>>> Index: b/drivers/net/wireless/rt2x00/rt2800pci.h
>>> ===================================================================
>>> --- a/drivers/net/wireless/rt2x00/rt2800pci.h
>>> +++ b/drivers/net/wireless/rt2x00/rt2800pci.h
>>> @@ -27,6 +27,27 @@
>>> #ifndef RT2800PCI_H
>>> #define RT2800PCI_H
>>>
>>> +static inline void rt2800_register_read(struct rt2x00_dev *rt2x00dev,
>>> + const unsigned int offset,
>>> + u32 *value)
>>> +{
>>> + rt2x00pci_register_read(rt2x00dev, offset, value);
>>> +}
>>> +
>>> +static inline void rt2800_register_write(struct rt2x00_dev *rt2x00dev,
>>> + const unsigned int offset,
>>> + u32 value)
>>> +{
>>> + rt2x00pci_register_write(rt2x00dev, offset, value);
>>> +}
>>> +
>>> +static inline void rt2800_register_write_lock(struct rt2x00_dev *rt2x00dev,
>>> + const unsigned int offset,
>>> + u32 value)
>>> +{
>>> + rt2x00pci_register_write(rt2x00dev, offset, value);
>>> +}
>>> +
>>> /*
>>> * RF chip defines.
>>> *
>>
>> Can we add a comment to the _lock variant explaining that this one
>> technically isn't
>> needed, but is present for alignment purposes with rt2800usb?
>
> I couldn't come with the good comment for it so I just went for
> the minimal one in patch #25 (which removed all quoted above inlines):
>
> +static const struct rt2800_ops rt2800pci_rt2800_ops = {
> + .register_read = rt2x00pci_register_read,
> + .register_write = rt2x00pci_register_write,
> + .register_write_lock = rt2x00pci_register_write, /* same for PCI */
> +
> + .register_multiread = rt2x00pci_register_multiread,
> + .register_multiwrite = rt2x00pci_register_multiwrite,
> +
> + .regbusy_read = rt2x00pci_regbusy_read,
> +};
>
> but it certainly can be expanded if somebody has a better idea how
> the comment should look like.
>
OK. Looks good enough for the moment. At least now there is some recognition
that it is not a bug / typo that the _write and _write_lock are the same on PCI.
With this change:
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
---
Gertjan.
^ permalink raw reply
* Re: [PATCH 00/41] rewritten rt2800 drivers
From: Gertjan van Wingerde @ 2009-11-06 19:56 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Luis R. Rodriguez, linux-wireless, Ivo van Doorn, linux-kernel,
John W. Linville
In-Reply-To: <200911061728.42531.bzolnier@gmail.com>
On 11/06/09 17:28, Bartlomiej Zolnierkiewicz wrote:
>
> I have also small process related suggestion: if possible please group ACKs
> together into the reply for 00/ mail (like you just did now), this way there
> is a higher chance that I will not lose some of ACKs or review comments.
>
Yep. No worries. Will do that for future patch series (which I hope will not be
as large as 41 patches anymore ;-))
---
Gertjan.
^ permalink raw reply
* [PATCH] ssb-pcmcia: Fix 32bit register access in early bus scanning
From: Michael Buesch @ 2009-11-06 20:21 UTC (permalink / raw)
To: John W. Linville; +Cc: Martin Fuzzey, Broadcom Wireless, linux-wireless
From: Martin Fuzzey <mfuzzey@gmail.com>
The scan function was using 32 bit access which does not
work on 16bit CF cards.
This patch corrects this by doing two 16 bit reads like
ssb_pcmcia_read32 already does.
mb -- Removed locking. That early in init there's no need for locking.
Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Index: wireless-testing/drivers/ssb/scan.c
===================================================================
--- wireless-testing.orig/drivers/ssb/scan.c 2009-10-09 19:50:16.000000000 +0200
+++ wireless-testing/drivers/ssb/scan.c 2009-11-06 19:24:13.000000000 +0100
@@ -162,6 +162,8 @@ static u8 chipid_to_nrcores(u16 chipid)
static u32 scan_read32(struct ssb_bus *bus, u8 current_coreidx,
u16 offset)
{
+ u32 lo, hi;
+
switch (bus->bustype) {
case SSB_BUSTYPE_SSB:
offset += current_coreidx * SSB_CORE_SIZE;
@@ -174,7 +176,9 @@ static u32 scan_read32(struct ssb_bus *b
offset -= 0x800;
} else
ssb_pcmcia_switch_segment(bus, 0);
- break;
+ lo = readw(bus->mmio + offset);
+ hi = readw(bus->mmio + offset + 2);
+ return lo | (hi << 16);
case SSB_BUSTYPE_SDIO:
offset += current_coreidx * SSB_CORE_SIZE;
return ssb_sdio_scan_read32(bus, offset);
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] Libertas: Fix issues while configuring host sleep
From: John W. Linville @ 2009-11-06 20:19 UTC (permalink / raw)
To: Bing Zhao; +Cc: libertas-dev, linux-wireless, Amitkumar Karwar
In-Reply-To: <1257383195-951-1-git-send-email-bzhao@marvell.com>
On Wed, Nov 04, 2009 at 05:06:35PM -0800, Bing Zhao wrote:
> From: Amitkumar Karwar <akarwar@marvell.com>
>
> Configuration of wake-on-lan for unicast, multicast, broadcast, physical
> activity was not working. Kernel panic issue was there when user tries to
> disable WOL. Fixed them.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
> ---
> drivers/net/wireless/libertas/ethtool.c | 16 +++++++++++-----
> 1 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> index 039b555..eeda6d7 100644
> --- a/drivers/net/wireless/libertas/ethtool.c
> +++ b/drivers/net/wireless/libertas/ethtool.c
> @@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
> struct lbs_private *priv = dev->ml_priv;
> uint32_t criteria = 0;
>
> - if (priv->wol_criteria == 0xffffffff && wol->wolopts)
> + if (priv->wol_criteria != 0xffffffff && wol->wolopts)
> return -EOPNOTSUPP;
Are you sure about this? This makes me think that you won't be able
to change WoL parameters without going through a disable step first.
Am I misreading?
> if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
> return -EOPNOTSUPP;
>
> - if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
> - if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> - if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> - if (wol->wolopts & WAKE_PHY) criteria |= EHS_WAKE_ON_MAC_EVENT;
> + if (wol->wolopts & WAKE_UCAST)
> + criteria |= EHS_WAKE_ON_UNICAST_DATA;
> + if (wol->wolopts & WAKE_MCAST)
> + criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> + if (wol->wolopts & WAKE_BCAST)
> + criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> + if (wol->wolopts & WAKE_PHY)
> + criteria |= EHS_WAKE_ON_MAC_EVENT;
> + if (wol->wolopts == 0)
> + criteria |= EHS_REMOVE_WAKEUP;
>
> return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
> }
The reformatting is a distraction. It would be better to do just
the fix part separately, especially if you are targetting 2.6.32.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Prism54/p54pci
From: Christian Lamparter @ 2009-11-06 20:33 UTC (permalink / raw)
To: James Grossmann; +Cc: linux-wireless
In-Reply-To: <167ae39b0911061137m72a1e7e9le0e2b59b64be2821@mail.gmail.com>
On Friday 06 November 2009 20:37:00 James Grossmann wrote:
> Doing it from the console doesn't seem to give a kernel oops... it
> just locks up the computer such that I can't even change the caps lock
> status. It starts the connection, and then the activity light on the
> card goes on and the computer is locked up.
well, there are other ways to capture the oops, but I don't think
your laptop has a serial console or a real reset button?!
does your caps lock & scroll lock LED blink? (they should)
does the kernel reboot itself (after ~10 seconds), if you add
panic=10
to the kernel-parameters in grub configuration?
do you have some sort of bootsplash or frame buffer console?
(e.g. KMS/vesa/etc...) because these advanced features can make it
really hard to get the message to the screen before it goes black.
is there nothing in /var/log/syslog after a crash?
> With regard to the losing connection/timing out, I'm seeing that a
> fair amount, when I have data transferring (watching an active ssh
> connection, or streaming audio), and especially when I'm not doing
> anything...
well, there could be several different things, I hope you're using
services like Network-manager, wpa_supplicant to manage your connection.
Because they will automatically reconnect as soon as the link dies.
what could be interesting: iw dev wlanX scan / iwlist wlanX scan
dump from your AP... especially the TSF/tsf value,
(it's a hexadecimal value which acts like a uptime for the AP)
Regards,
Chr
^ permalink raw reply
* pull request: wireless-2.6 2009-11-06
From: John W. Linville @ 2009-11-06 20:40 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Three more intended for 2.6.32, two oops fixes and a revert of a patch
that traded one bug for another. One of the oops fixes reorders some
cancel_delayed_work_sync calls and the other does some bit testing to
avoid scheduling work after a device has been removed.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit bcfe3c2046fc4f16544f2b127f1b159dd1fcad8b:
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
John W. Linville (1):
Revert "ipw2200: fix oops on missing firmware"
Larry Finger (1):
rtl8187: Fix kernel oops when device is removed when LEDS enabled
Sean Cross (1):
rt2x00: Don't queue ieee80211 work after USB removal
drivers/net/wireless/ipw2x00/ipw2100.c | 5 +----
drivers/net/wireless/ipw2x00/ipw2200.c | 2 --
drivers/net/wireless/ipw2x00/libipw.h | 1 -
drivers/net/wireless/ipw2x00/libipw_module.c | 14 +++++---------
drivers/net/wireless/rt2x00/rt2x00dev.c | 4 ++--
drivers/net/wireless/rt2x00/rt2x00link.c | 11 +++++++----
drivers/net/wireless/rt2x00/rt2x00usb.c | 9 ++++++++-
drivers/net/wireless/rtl818x/rtl8187_leds.c | 4 ++--
8 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
index a741d37..240cff1 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -6325,10 +6325,8 @@ static int ipw2100_pci_init_one(struct pci_dev *pci_dev,
fail:
if (dev) {
- if (registered) {
- unregister_ieee80211(priv->ieee);
+ if (registered)
unregister_netdev(dev);
- }
ipw2100_hw_stop_adapter(priv);
@@ -6385,7 +6383,6 @@ static void __devexit ipw2100_pci_remove_one(struct pci_dev *pci_dev)
/* Unregister the device first - this results in close()
* being called if the device is open. If we free storage
* first, then close() will crash. */
- unregister_ieee80211(priv->ieee);
unregister_netdev(dev);
/* ipw2100_down will ensure that there is no more pending work
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 04341a2..8d58e6e 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -11821,7 +11821,6 @@ static int __devinit ipw_pci_probe(struct pci_dev *pdev,
if (err) {
IPW_ERROR("Failed to register promiscuous network "
"device (error %d).\n", err);
- unregister_ieee80211(priv->ieee);
unregister_netdev(priv->net_dev);
goto out_remove_sysfs;
}
@@ -11872,7 +11871,6 @@ static void __devexit ipw_pci_remove(struct pci_dev *pdev)
mutex_unlock(&priv->mutex);
- unregister_ieee80211(priv->ieee);
unregister_netdev(priv->net_dev);
if (priv->rxq) {
diff --git a/drivers/net/wireless/ipw2x00/libipw.h b/drivers/net/wireless/ipw2x00/libipw.h
index f42ade6..bf45391 100644
--- a/drivers/net/wireless/ipw2x00/libipw.h
+++ b/drivers/net/wireless/ipw2x00/libipw.h
@@ -1020,7 +1020,6 @@ static inline int libipw_is_cck_rate(u8 rate)
/* ieee80211.c */
extern void free_ieee80211(struct net_device *dev, int monitor);
extern struct net_device *alloc_ieee80211(int sizeof_priv, int monitor);
-extern void unregister_ieee80211(struct libipw_device *ieee);
extern int libipw_change_mtu(struct net_device *dev, int new_mtu);
extern void libipw_networks_age(struct libipw_device *ieee,
diff --git a/drivers/net/wireless/ipw2x00/libipw_module.c b/drivers/net/wireless/ipw2x00/libipw_module.c
index be5b809..a0e9f6a 100644
--- a/drivers/net/wireless/ipw2x00/libipw_module.c
+++ b/drivers/net/wireless/ipw2x00/libipw_module.c
@@ -235,19 +235,16 @@ void free_ieee80211(struct net_device *dev, int monitor)
libipw_networks_free(ieee);
/* free cfg80211 resources */
- if (!monitor)
+ if (!monitor) {
+ wiphy_unregister(ieee->wdev.wiphy);
+ kfree(ieee->a_band.channels);
+ kfree(ieee->bg_band.channels);
wiphy_free(ieee->wdev.wiphy);
+ }
free_netdev(dev);
}
-void unregister_ieee80211(struct libipw_device *ieee)
-{
- wiphy_unregister(ieee->wdev.wiphy);
- kfree(ieee->a_band.channels);
- kfree(ieee->bg_band.channels);
-}
-
#ifdef CONFIG_LIBIPW_DEBUG
static int debug = 0;
@@ -333,4 +330,3 @@ module_init(libipw_init);
EXPORT_SYMBOL(alloc_ieee80211);
EXPORT_SYMBOL(free_ieee80211);
-EXPORT_SYMBOL(unregister_ieee80211);
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 71761b3..73bbec5 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -815,6 +815,8 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
mutex_init(&rt2x00dev->csr_mutex);
+ set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
+
/*
* Make room for rt2x00_intf inside the per-interface
* structure ieee80211_vif.
@@ -871,8 +873,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
rt2x00leds_register(rt2x00dev);
rt2x00debug_register(rt2x00dev);
- set_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
-
return 0;
exit:
diff --git a/drivers/net/wireless/rt2x00/rt2x00link.c b/drivers/net/wireless/rt2x00/rt2x00link.c
index c64db0b..c708d0b 100644
--- a/drivers/net/wireless/rt2x00/rt2x00link.c
+++ b/drivers/net/wireless/rt2x00/rt2x00link.c
@@ -362,8 +362,9 @@ void rt2x00link_start_tuner(struct rt2x00_dev *rt2x00dev)
rt2x00link_reset_tuner(rt2x00dev, false);
- ieee80211_queue_delayed_work(rt2x00dev->hw,
- &link->work, LINK_TUNE_INTERVAL);
+ if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ ieee80211_queue_delayed_work(rt2x00dev->hw,
+ &link->work, LINK_TUNE_INTERVAL);
}
void rt2x00link_stop_tuner(struct rt2x00_dev *rt2x00dev)
@@ -469,8 +470,10 @@ static void rt2x00link_tuner(struct work_struct *work)
* Increase tuner counter, and reschedule the next link tuner run.
*/
link->count++;
- ieee80211_queue_delayed_work(rt2x00dev->hw,
- &link->work, LINK_TUNE_INTERVAL);
+
+ if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ ieee80211_queue_delayed_work(rt2x00dev->hw,
+ &link->work, LINK_TUNE_INTERVAL);
}
void rt2x00link_register(struct rt2x00_dev *rt2x00dev)
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index 5015448..f02b48a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -47,6 +47,8 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
(requesttype == USB_VENDOR_REQUEST_IN) ?
usb_rcvctrlpipe(usb_dev, 0) : usb_sndctrlpipe(usb_dev, 0);
+ if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ return -ENODEV;
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
status = usb_control_msg(usb_dev, pipe, request, requesttype,
@@ -60,8 +62,10 @@ int rt2x00usb_vendor_request(struct rt2x00_dev *rt2x00dev,
* -ENODEV: Device has disappeared, no point continuing.
* All other errors: Try again.
*/
- else if (status == -ENODEV)
+ else if (status == -ENODEV) {
+ clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
break;
+ }
}
ERROR(rt2x00dev,
@@ -161,6 +165,9 @@ int rt2x00usb_regbusy_read(struct rt2x00_dev *rt2x00dev,
{
unsigned int i;
+ if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ return -ENODEV;
+
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
rt2x00usb_register_read_lock(rt2x00dev, offset, reg);
if (!rt2x00_get_field32(*reg, field))
diff --git a/drivers/net/wireless/rtl818x/rtl8187_leds.c b/drivers/net/wireless/rtl818x/rtl8187_leds.c
index a1c670f..cf8a4a4 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -210,10 +210,10 @@ void rtl8187_leds_exit(struct ieee80211_hw *dev)
/* turn the LED off before exiting */
ieee80211_queue_delayed_work(dev, &priv->led_off, 0);
- cancel_delayed_work_sync(&priv->led_off);
- cancel_delayed_work_sync(&priv->led_on);
rtl8187_unregister_led(&priv->led_rx);
rtl8187_unregister_led(&priv->led_tx);
+ cancel_delayed_work_sync(&priv->led_off);
+ cancel_delayed_work_sync(&priv->led_on);
}
#endif /* def CONFIG_RTL8187_LED */
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: b43: firmware loading problem and sleeping BUG
From: Michael Buesch @ 2009-11-06 20:45 UTC (permalink / raw)
To: Martin Fuzzey; +Cc: linux-wireless
In-Reply-To: <200911062008.06159.mb@bu3sch.de>
On Friday 06 November 2009 20:08:04 Michael Buesch wrote:
> On Friday 06 November 2009 19:27:17 Martin Fuzzey wrote:
> > > I think this is easy to fix, because we can replace the spinlock by a mutex, as
> > > the b43 driver (which is the only user of the code) always allows sleeping now.
> > > I'll send a patch for testing soon.
> > >
> > Great - happy to test it.
>
> There you go.
This doesn't actually work, because the lowlevel interrupt handler is atomic on PCMCIA.
So scratch that patch, it will just oops your machine.
--
Greetings, Michael.
^ permalink raw reply
* Re: Prism54/p54pci
From: James Grossmann @ 2009-11-06 20:52 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <200911062133.38842.chunkeey@googlemail.com>
my caps lock & scroll lock leds are not blinking, and yet the computer
is frozen. (I'm not the best at terminology, I guess that might not
be defined as a hard lock.) I get no odd messages in my syslog. I am
using Ubuntu right now, so I'm guessing that they have all the
prettyness going that they can, covering the important messages, but
as it's not an actual oops, I'm not certain that's hurting us.
I am using network-manager, so it does reconnect, however, I find that
to be less than optimal.
Thanks,
James
On Fri, Nov 6, 2009 at 2:33 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Friday 06 November 2009 20:37:00 James Grossmann wrote:
>> Doing it from the console doesn't seem to give a kernel oops... it
>> just locks up the computer such that I can't even change the caps lock
>> status. It starts the connection, and then the activity light on the
>> card goes on and the computer is locked up.
> well, there are other ways to capture the oops, but I don't think
> your laptop has a serial console or a real reset button?!
>
> does your caps lock & scroll lock LED blink? (they should)
>
> does the kernel reboot itself (after ~10 seconds), if you add
> panic=10
> to the kernel-parameters in grub configuration?
>
> do you have some sort of bootsplash or frame buffer console?
> (e.g. KMS/vesa/etc...) because these advanced features can make it
> really hard to get the message to the screen before it goes black.
>
> is there nothing in /var/log/syslog after a crash?
>
>> With regard to the losing connection/timing out, I'm seeing that a
>> fair amount, when I have data transferring (watching an active ssh
>> connection, or streaming audio), and especially when I'm not doing
>> anything...
> well, there could be several different things, I hope you're using
> services like Network-manager, wpa_supplicant to manage your connection.
> Because they will automatically reconnect as soon as the link dies.
>
> what could be interesting: iw dev wlanX scan / iwlist wlanX scan
> dump from your AP... especially the TSF/tsf value,
> (it's a hexadecimal value which acts like a uptime for the AP)
>
> Regards,
> Chr
>
^ permalink raw reply
* Re: [PATCH 15/28] mwl8k: change pci id table driver data to a structure pointer
From: John W. Linville @ 2009-11-06 20:57 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: linux-wireless
In-Reply-To: <20091022182046.GQ1583@mail.wantstofly.org>
On Thu, Oct 22, 2009 at 08:20:47PM +0200, Lennert Buytenhek wrote:
> To prepare for adding support for more device types, introduce a
> new structure, mwl8k_device_info, where per-device information can
> be stored, and change the pci id table driver data from an integer
> indicating only the part number to a pointer to a mwl8k_device_info
> structure.
>
> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> ---
> drivers/net/wireless/mwl8k.c | 47 ++++++++++++++++++++++++++---------------
> 1 files changed, 30 insertions(+), 17 deletions(-)
> @@ -2940,6 +2936,22 @@ static void mwl8k_finalize_join_worker(struct work_struct *work)
> priv->beacon_skb = NULL;
> }
>
> +static struct mwl8k_device_info di_8687 = {
> + .part_num = 8687,
> +};
> +
> +static DEFINE_PCI_DEVICE_TABLE(mwl8k_pci_id_table) = {
> + {
> + PCI_VDEVICE(MARVELL, 0x2a2b),
> + .driver_data = (unsigned long)&di_8687,
> + }, {
> + PCI_VDEVICE(MARVELL, 0x2a30),
> + .driver_data = (unsigned long)&di_8687,
> + }, {
> + },
> +};
> +MODULE_DEVICE_TABLE(pci, mwl8k_pci_id_table);
> +
> static int __devinit mwl8k_probe(struct pci_dev *pdev,
> const struct pci_device_id *id)
> {
My only complaint here is that using a pointer for
driver_data make it difficult and potentially dangerous to use
/sys/bus/pci/drivers/.../new_id to add a PCI ID to the device.
Using an integer instead makes that a bit safer and easier to use.
drivers/net/3c59x.c provides a decent example.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* gui wireless tools for moblin
From: jack craig @ 2009-11-06 20:45 UTC (permalink / raw)
To: linux-wireless
Hi Wireless Folks,
I just installed the Moblin 2.1 on my EeePC with a new Intel 4965 under the
hood. Naturally, my wireless access is working a Lot better than it did.
However, the wireless control panel in my moblin is underwhelming.
I am wondering if someone on thei group could point me to a wireless gui app
that would graphically reveal local networks, signal strength and type (a/g/n)?
from the current display, I cant tell if I am running on a g network or an n;
i'd like to know.
any pointers? thx, jackc...
^ permalink raw reply
* RE: [PATCH] Libertas: Fix issues while configuring host sleep
From: Bing Zhao @ 2009-11-06 21:27 UTC (permalink / raw)
To: John W. Linville
Cc: libertas-dev@lists.infradead.org, linux-wireless@vger.kernel.org,
Amitkumar Karwar
In-Reply-To: <20091106201924.GH2782@tuxdriver.com>
Hi John,
> -----Original Message-----
> From: John W. Linville [mailto:linville@tuxdriver.com]
> Sent: Friday, November 06, 2009 12:19 PM
> To: Bing Zhao
> Cc: libertas-dev@lists.infradead.org; linux-wireless@vger.kernel.org; Amitkumar Karwar
> Subject: Re: [PATCH] Libertas: Fix issues while configuring host sleep
>
> On Wed, Nov 04, 2009 at 05:06:35PM -0800, Bing Zhao wrote:
> > From: Amitkumar Karwar <akarwar@marvell.com>
> >
> > Configuration of wake-on-lan for unicast, multicast, broadcast, physical
> > activity was not working. Kernel panic issue was there when user tries to
> > disable WOL. Fixed them.
> >
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > Signed-off-by: Bing Zhao <bzhao@marvell.com>
> > ---
> > drivers/net/wireless/libertas/ethtool.c | 16 +++++++++++-----
> > 1 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> > index 039b555..eeda6d7 100644
> > --- a/drivers/net/wireless/libertas/ethtool.c
> > +++ b/drivers/net/wireless/libertas/ethtool.c
> > @@ -169,16 +169,22 @@ static int lbs_ethtool_set_wol(struct net_device *dev,
> > struct lbs_private *priv = dev->ml_priv;
> > uint32_t criteria = 0;
> >
> > - if (priv->wol_criteria == 0xffffffff && wol->wolopts)
> > + if (priv->wol_criteria != 0xffffffff && wol->wolopts)
> > return -EOPNOTSUPP;
>
> Are you sure about this? This makes me think that you won't be able
> to change WoL parameters without going through a disable step first.
> Am I misreading?
I'm not sure if this is the best fix or not. But without this change, "ethtool -s wlan0 wol u" would return "Cannot set new wake-on-lan settings: Operation not supported". Yes, you have to disable it first in order to change the WoL parameters.
>
> > if (wol->wolopts & ~(WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY))
> > return -EOPNOTSUPP;
> >
> > - if (wol->wolopts & WAKE_UCAST) criteria |= EHS_WAKE_ON_UNICAST_DATA;
> > - if (wol->wolopts & WAKE_MCAST) criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> > - if (wol->wolopts & WAKE_BCAST) criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> > - if (wol->wolopts & WAKE_PHY) criteria |= EHS_WAKE_ON_MAC_EVENT;
> > + if (wol->wolopts & WAKE_UCAST)
> > + criteria |= EHS_WAKE_ON_UNICAST_DATA;
> > + if (wol->wolopts & WAKE_MCAST)
> > + criteria |= EHS_WAKE_ON_MULTICAST_DATA;
> > + if (wol->wolopts & WAKE_BCAST)
> > + criteria |= EHS_WAKE_ON_BROADCAST_DATA;
> > + if (wol->wolopts & WAKE_PHY)
> > + criteria |= EHS_WAKE_ON_MAC_EVENT;
> > + if (wol->wolopts == 0)
> > + criteria |= EHS_REMOVE_WAKEUP;
> >
> > return lbs_host_sleep_cfg(priv, criteria, (struct wol_config *)NULL);
> > }
>
> The reformatting is a distraction. It would be better to do just
> the fix part separately, especially if you are targetting 2.6.32.
Without the reformatting, the change would be like this:
+ if (wol->wolopts == 0) criteria |= EHS_REMOVE_WAKEUP;
But the "checkpatch.pl" script gave me an error on that:
"ERROR: trailing statements should be on next line"
Thanks,
Bing
> John
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Changing from Minstrel to PID
From: Martín Ernesto Barreyro @ 2009-11-06 21:29 UTC (permalink / raw)
To: linux-wireless
Hello, I have a rtl8187 wireless card and I've allways have problems
with the rate control using minstrel. So everytime my kernel updates
(recently it went from 2.30 to 2.31) i have to recompile mi kernel
setting pid as my default rate control algorithm.
Is there a way to change that without compiling the kernel?
--
Martín Ernesto Barreyro <barreyromartin@gmail.com>
Analista Universitario en Redes de Datos.
^ permalink raw reply
* [PATCH] mwl8k: use integral index instead of pointer for driver_data
From: John W. Linville @ 2009-11-06 21:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Lennert Buytenhek, John W. Linville
Use of an integral index makes adding new device IDs through sysfs more
practical.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/mwl8k.c | 47 ++++++++++++++++++++---------------------
1 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 9fde17b..2ebfee4 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -3308,34 +3308,33 @@ static void mwl8k_finalize_join_worker(struct work_struct *work)
priv->beacon_skb = NULL;
}
-static struct mwl8k_device_info di_8366 = {
- .part_name = "88w8366",
- .helper_image = "mwl8k/helper_8366.fw",
- .fw_image = "mwl8k/fmimage_8366.fw",
- .rxd_ops = &rxd_8366_ops,
- .modes = 0,
+enum {
+ MWL8687 = 0,
+ MWL8366,
};
-static struct mwl8k_device_info di_8687 = {
- .part_name = "88w8687",
- .helper_image = "mwl8k/helper_8687.fw",
- .fw_image = "mwl8k/fmimage_8687.fw",
- .rxd_ops = &rxd_8687_ops,
- .modes = BIT(NL80211_IFTYPE_STATION),
+static struct mwl8k_device_info mwl8k_info_tbl[] __devinitdata = {
+ {
+ .part_name = "88w8687",
+ .helper_image = "mwl8k/helper_8687.fw",
+ .fw_image = "mwl8k/fmimage_8687.fw",
+ .rxd_ops = &rxd_8687_ops,
+ .modes = BIT(NL80211_IFTYPE_STATION),
+ },
+ {
+ .part_name = "88w8366",
+ .helper_image = "mwl8k/helper_8366.fw",
+ .fw_image = "mwl8k/fmimage_8366.fw",
+ .rxd_ops = &rxd_8366_ops,
+ .modes = 0,
+ },
};
static DEFINE_PCI_DEVICE_TABLE(mwl8k_pci_id_table) = {
- {
- PCI_VDEVICE(MARVELL, 0x2a2b),
- .driver_data = (unsigned long)&di_8687,
- }, {
- PCI_VDEVICE(MARVELL, 0x2a30),
- .driver_data = (unsigned long)&di_8687,
- }, {
- PCI_VDEVICE(MARVELL, 0x2a40),
- .driver_data = (unsigned long)&di_8366,
- }, {
- },
+ { PCI_VDEVICE(MARVELL, 0x2a2b), .driver_data = MWL8687, },
+ { PCI_VDEVICE(MARVELL, 0x2a30), .driver_data = MWL8687, },
+ { PCI_VDEVICE(MARVELL, 0x2a40), .driver_data = MWL8366, },
+ { },
};
MODULE_DEVICE_TABLE(pci, mwl8k_pci_id_table);
@@ -3379,7 +3378,7 @@ static int __devinit mwl8k_probe(struct pci_dev *pdev,
priv = hw->priv;
priv->hw = hw;
priv->pdev = pdev;
- priv->device_info = (void *)id->driver_data;
+ priv->device_info = &mwl8k_info_tbl[id->driver_data];
priv->rxd_ops = priv->device_info->rxd_ops;
priv->sniffer_enabled = false;
priv->wmm_enabled = false;
--
1.6.2.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox