The patch allows the user to set the handover threshold, i.e. the number
of consecutively missed beacons that will trigger a roaming attempt. The
disassociation threshold is set to 3 times the handover threshold.
Signed-off-by: NOlivier Hochreutiner <olivier.hochreutiner@epfl.ch>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This forces one antenna or the other, if the background noise is
significantly quieter in one than the other. It favors the quieter
antenna, and won't kick in unless the difference is significant.
Signed-off-by: NCahill, Ben M <ben.m.cahill@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Set a meaningful silence threshold value (replacing our previous "0"
default), which gets rid of the gratuitous "Link deterioration"
notifications that we've been receiving from firmware.  This
notification feature tells the driver information to help it determine
when to pre-emptively restart the firmware/ucode in anticipation of
firmware errors!  But since setting this new threshold, I haven't seen
any such notifications.  At least it keeps the logs a little less busy.
Signed-off-by: NCahill, Ben M <ben.m.cahill@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently iwlist ethX freq[uency]/channel lists all the channels the card
supported for the current region, which includes some channels can only
be used in infrastructure mode. This patch filters these channels out if
the card is currently in ad-hoc mode.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When loading the ipw2200 module with disabled=1, rf_kill is activated after
every mode change. This is caused by ipw_sw_reset() is called when a mode
is changed. The patch fixed the problem by distinguishing the purposes with
the 'option' paramenter.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wpa_supplicant needs to set wpa_enabled unconditionally, with this check
it hasn't been possible to connect to non-WPA networks using wpa_supplicant.
So remove below check.

if (priv->ieee->wpa_enabled &&
	network->wpa_ie_len == 0 && network->rsn_ie_len == 0)
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch does two things. It uses the parameter IW_QUAL_DBM which is new
in WE-19 to cause signal level and noise to be reported in dBm by the
wireless tools. It also defines the signal level as an unsigned integer
so that the signal level will be reported by iwlist iface scan.
Signed-off-by: NBill Moss <bmoss@clemson.edu>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

replace ipw2200 specific frame_hdr_len() with generic
ieee80211 routine ieee80211_get_hdrlen()
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Only on CONFIG_IPW2200_DEBUG is not defined
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch roll back the change we made to support for the ability to
start/stop independent Tx queues within a single net device in order to
support 802.11e QoS. We need to be able to indicate to the upper layers
that packets of a given priority can not be sent any more without halting
transmission of all packets, and without rescheduling high priority packets
down to the next priority level.

So we return NETDEV_TX_BUSY in this case and rely on the stack would
take care of rescheduling... which it apparently does immediately and
consumes the CPU. This caused the ksoftirqd kernel thread consuming almost
all the CPU...

To put the code back to the way it was before we made these changes we
put the call netif_queue_stop back in ipw_tx_skb.  This effectively
disables multiple priority based transmit queues for 802.11e, but given
that its broken anyway...
Signed-off-by: NJames Ketrenos <jketreno@linux.intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Given the amount of support requests for the meaning of the geography code
I've written a patch for printing this information on module load no matter
the debug level.

I've also added a section to the README.ipw2200 file listing the geography
codes and their meaning.
Signed-off-by: NHenrik Brix Andersen <brix@gentoo.org>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch makes the needlessly global function ipw_qos_current_mode()
static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As stated in a comment, the ipw2200 driver uses several routines that
were borrowed from ieee80211_geo.c. As ipw2200 requires ieee80211,
these routines are duplicated. The attached patch, which is sent
as an attachment to preserve whitespace, converts ipw2200.c to use
the ieee80211 versions, thereby reducing bloat in both the source
and binary.
Signed-Off-By: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The following message will be only printed if DEBUG_NOTIF is on.  "Unknown
notification: subtype=40,flags=0xa0,size=40"
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Cc: James Ketrenos <jketreno@linux.intel.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We didn't set the WEP key to hardware when we are using software based
crypto. Hardware needs the key to do WEP authentication even for
software based encryption.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Do not avoid APs with wpa_ie or rsn_ie if !ieee->wpa_enabled
There are broken APs out there that fill these elements even
though encryption is disnabled. Also, this breaks legit WEP to
WPA migration scenarious.

We add a checking to prohibite WPA configured STA trying to
associate with non-WPA supported APs.
Signed-off-by: NStefan Rompf <stefan@loplof.de>
Signed-off-by: NJames Ketrenos <jketreno@linux.intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

priv->eeprom is a pointer.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Acked-by: NYi Zhu <yi.zhu@intel.com>
Cc: James Ketrenos <jketreno@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch allows ipw2100 driver to advertise the WPA-related encryption
options that it does really support.  It's necessary to work correctly
with NetworkManager and other programs that actually check driver & card
capabilities.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After looking at the mailing list (and experiencing permanent driver lockups
while using hwcrypto=1) I think that disabling this option by default would
be better than otherwise.
Signed-off-by: NAndreas Happe <andreashappe@snikt.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: Ronald Bultje <rbultje@ronald.bitfreak.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Garzik <jgarzik@pobox.com>
Cc: Yi Zhu <yi.zhu@intel.com>
Cc: James Ketrenos <jketreno@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJames Ketrenos <jketreno@linux.intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

increase ipw2200 driver version to git-1.0.10
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch fixes a couple of errors regarding QoS, which results in
compile warnings and malfunction of the driver.
Signed-off-by: NHenrik Brix Andersen <brix@gentoo.org>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Checking the stack usage of my kernel, showed that ipw2200 had a few bad
offenders. This is on i386 32-bit:

0x00002876 ipw_send_associate:                          544
0x000028ee ipw_send_associate:                          544
0x000027dc ipw_send_scan_request_ext:                   520
0x00002864 ipw_set_sensitivity:                         520
0x00005eac ipw_set_rsn_capa:                            520

The reason is the host_cmd structure is large (500 bytes). All other
functions currently using ipw_send_cmd() suffer from the same problem.
This patch introduces ipw_send_cmd_simple() for commands with no data
transfer, and ipw_send_cmd_pdu() for commands with a data payload and
makes the payload a pointer to the buffer passed in from the caller.

As an added bonus, the diffstat looks like this:

 ipw2200.c |  260 +++++++++++++++++++++-----------------------------------------
 ipw2200.h |    2
 2 files changed, 92 insertions(+), 170 deletions(-)

and it shrinks the module a lot as well:

Before:

   text    data     bss     dec     hex filename
  75177    2472      44   77693   12f7d drivers/net/wireless/ipw2200.ko

After:

   text    data     bss     dec     hex filename
  61363    2488      44   63895    f997 drivers/net/wireless/ipw2200.ko

So about a ~18% reduction in module size.
Signed-off-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I can't really help with why restarts happen, but the following patch
greatly increases the likelihood that a firmware reload will succeed
afterward on my thinkpad. It addresses two issues. First, sysfs module
loading and hotplug are asynchronous, and as such file operations on the
"loading" and "data" files are racy when you load 2 firmwares in quick
succession. Second, the timeout for DMAing the firmware needs to scale
with the size of the firmware being loaded. That is, the watchdog needs
to be on throughput, not on time alone.

I no longer get the firmware load errors, though this is at best a hacky
workaround for a racy interface. (Obviously, this does nothing to address
the fatal errors in firmware which cause reloads; it just causes the
initial loading and the reloads to work more often.)
Signed-off-by: NPeter Jones <pjones@redhat.com>
Signed-off-by: NBen M Cahill <ben.m.cahill@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: Clemens Buchacher <drizzd@aon.at>.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This substitutes Linux jiffies_to_msec() wherever there is a
computation for determining milliseconds from jiffies,
following lead from ieee80211 code. And it does a little cleanup.
"it's" == "it is" ... "its" == possessive "it". Indulge me. ;-)
Signed-off-by: NCahill, Ben M <ben.m.cahill@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I've added a new module param "bt_coexist" which defaults to OFF.

This does not seem to fix the firmware restarts, but it does do "the
right thing" and disables something that we were enabling by default:
signaling the Bluetooth h/w which channel we're on (whether or not the
BT h/w was out there).
Signed-off-by: NBen M Cahill <ben.m.cahill@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHong Liu <hong.liu@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NNick Kralevich <nick.ipw2200@kralevich.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The indirect SRAM/register 8/16-bit write routines are broken for
non-dword-aligned destination addresses.

Fortunately, these routines are, so far, not used for non-dword-aligned
destinations, but here's a patch that fixes them, anyway.

The attached patch also adds comments for all direct/indirect I/O routine
variations.
Signed-off-by: NBen M Cahill <ben.m.cahill@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch contains the following possible cleanups:
- make needlessly global functions static
- "extern inline" -> "static inline"
- #if 0 the unused global function ipw_led_activity_on()
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHong Liu <hong.liu@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Drivers should not sleep for very long inside an ioctl -
so return EAGAIN and let wpa_supplicant handle the problem.
Signed-off-by: NOlaf Kirch <okir@suse.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>