We need to make sure we don't associate with APs on unallowed
channels (according to regulatory setting). This could happen
when the channel is not specified (auto-select) within the
connection request. In this case we get the AP's channel until
the firmware indicates the association succeeded later. We need
to verify the associated channel. If the channel is disabled by
regulatory, we have to disassociate with the AP.

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

The wrong pointer was tested.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Without this header, we can trigger a UMAC crash with debug enabled UMACs.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This reverts commit 6c853da3.

From Message-ID: <1262663293.551.117.camel@debian>
On Sat, 2010-01-02 at 22:09 +0800, Dan Carpenter wrote:
> It don't think 6c853da3 is right.  That's the patch
> titled "iwmc3200wifi: fix array out-of-boundary access"
>
>       Allocate priv->rx_packets[IWM_RX_ID_HASH + 1] because the max array
>       index is IWM_RX_ID_HASH according to IWM_RX_ID_GET_HASH().
>
> In 2.6.33-rc2 IWM_RX_ID_GET_HASH() doesn't go as high as IWM_RX_ID_HASH
> and I don't see any array out-of-bounds.
>
> #define IWM_RX_ID_GET_HASH(id) ((id) % IWM_RX_ID_HASH)

Ah, you are right. I took '%' for '&'. John, would you revert it? Sorry
for the false alarm.

Thanks,
-yi

Reported-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Allocate priv->rx_packets[IWM_RX_ID_HASH + 1] because the max array
index is IWM_RX_ID_HASH according to IWM_RX_ID_GET_HASH().

Cc: stable@kernel.org
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Determine the offset at compile time.

Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When the device receives an A-MSDU frame (indicated by flag
IWM_RX_TICKET_AMSDU_MSK), use ieee80211_amsdu_to_8023s to convert
it to a list of 802.3 frames and handled them to upper layer.

Cc: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Samuel Ortiz <samuel@sortiz.org>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

`queue' was unsigned so the test did not work.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Reviewed-by: Pavel Roskin <proski@gnu.org>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When debugging the wifi firmware, we need to disable the wimax core to gain
some memory space. The default value will keep the wimax core enabled.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Wifi and wimax coexistence mode is set by wifi at boot time. There can be
several modes, defined by priority tables. User space components can decide
which one to select by writing to /sys/module/iwmc3200wifi/parameters/wiwi
with this patch, before bringing the interface up.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When sending the wiwi coexistence priority table, we should not tell the LMAC
that we want a response.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This update follows the firmware engineers recommendations.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When handling IWM_CMD_PMKID_FLUSH command, the bssid and
pmkid in pmksa are all NULL. Check it before memcpy.

Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

We need to implement the PMKSA API for proper WPA2 pre-auth and fast
re-association. Our fullmac device generates all (re-)assoc IEs, and thus it
needs the right PMKIDs. With this implementation we now get them from
wpa_supplicant.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The tx concatenation option works fine now, we no longer need the debugging
option of disabling concatenation.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We add the stopped queue count and display to the tx queue debugfs entry.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

To support 802.11n Tx aggregation support with iwmc3200 wifi, we have to
handle the UMAC_CMD_OPCODE_STOP_RESUME_STA_TX notification from the UMAC.
Before sending an AddBA, the UMAC synchronizes with the host in order to
know what is the last Tx frame it's supposed to receive before it will be
able to start the actual aggregation session.
We thus have to keep track of the last sequence number that is scheduled
for transmission on a particular RAxTID, send an answer to the UMAC with
this sequence number. The UMAC then does the BA negociation and once it's
done with it sends a new UMAC_CMD_OPCODE_STOP_RESUME_STA_TX notification
to let us know that we can resume the Tx flow on the specified RAxTID.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Set the wireless mode with regard to both the driver's configuration
and the device's EEPROM result.

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

The iwmc3200wifi eeprom contains information about the available PHYs on
the chip. We should update our wireless_mode setting and profile according
to it.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When we're down, we shouldnt try to set the UMAC power limit. We just return 0
instead, and cfg80211 toggles the soft rfkill state.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The fat channels eeprom entries let us know if 11n is enabled or not. We
update our wiphy supported bands based on that.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

With the WLAN_PRE80211 drivers moved to drivers/staging, this
distinction becomes unnecessary.

Signed-off-by: John W. Linville <linville@tuxdriver.com>

Handle WiFi/WiMax coexistence radio preemption notification event.

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

Our wiphy firmware version is a combination of the UMAC and LMAC ones.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We can receive unexpected reboot barker at any time, and we're supposed to
reset the whole device then.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When we fail to associate with an open WEP AP, we fall back to shared auth.
This allows us to support joining a shared auth WEP AP with iwconfig.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When resetting or bringing the interface down, we should just reject any wifi
related command.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The wifi_if_wrapper notification handling code uses a cmd pointer without
checking if it's valid or not. We're dereferencing it because we assume that
we only get to that point if there was a pending command for us. That's not
always true, so we'd better check.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When calling sdio->bus_disable(), we are flushing the command lists before
disabling the sdio function. We can thus potentially get a command response
after having flushed the command list.
To avoid that race, we have to call iwm_reset() after disabling the sdio
function.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We can now set the Tx power from e.g. iwconfig.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We need to be in sync with the latest firmware API.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The latest firmware adds a ht_rates and a chain_energy field. The latter is
needed as we want to eventually support RSSI/antenna handling.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We display the correct DROP/RELEASE string for each rx packets, and when
it's dropped we also display the reason.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

UMAC will ASSERT if the profile security flag is WPA1 | WPA2, so we can only
accept one of those.
Moreover wpa_s wext and nl80211 drivers dont try to send WPA1 | WPA2, but only
one at a time.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We set the initial CT (Temperature control) value to 110 degrees.
If the chip goes over that threshold, we hard block the device which will turn
it down. At the same time we schedule a 30 seconds delayed work that unblock
the device (and userspace is supposed to bring it back up), hoping that the
chip will have cooled down by then...

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

By setting the WSC profile flag, we now support WPS as an enrollee.

Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We used to only support creating a new IBSS network. Now joining to
an existed IBSS network is supported as well.

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

Add BGN SKU sdio device id.

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