module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
(Thanks to Joe Perches for suggesting coccinelle for 0/1 -> true/false).
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
DaveM said:
Please, this kind of stuff rots forever and not using bool properly
drives me crazy.
Joe Perches <joe@perches.com> gave me the spatch script:
@@
bool b;
@@
-b = 0
+b = false
@@
bool b;
@@
-b = 1
+b = true
I merely installed coccinelle, read the documentation and took credit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
tx params should be configured per interface.
add ieee80211_vif param to the conf_tx callback,
and change all the drivers that use this callback.
The following spatch was used:
@rule1@
struct ieee80211_ops ops;
identifier conf_tx_op;
@@
ops.conf_tx = conf_tx_op;
@rule2@
identifier rule1.conf_tx_op;
identifier hw, queue, params;
@@
conf_tx_op (
- struct ieee80211_hw *hw,
+ struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u16 queue,
const struct ieee80211_tx_queue_params *params) {...}
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This will avoid mac80211 to trigger PS mode for connected station
based on the PM bit of incoming frames. AP firmware is capable of
handling such frames and buffering TX frames destined to the
stations that are in PS mode.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When a client disassociates from a crypto enabled bss, data traffic to
other clients connected to the bss is stalled. This was due to a boolean
variable used to keep track if HW crypto is enabled i.e. if set key has
been called to add a key. This flag was being reset every time delete
key was called e.g when a station leaves the bss. Once the flag is
reset, rx status flags were not being set for connected clients which
disrupts traffic to these clients. Fix this issue by not resetting the
flag since we do not need to reset this flag during the life time of the
bss.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Following oops was seen on SMP machine
>BUG: unable to handle kernel NULL pointer dereference at 00000012
>IP: [<f8c56691>] mwl8k_tx+0x20e/0x561 [mwl8k]
>*pde = 00000000
>Oops: 0000 [#1] SMP
>Modules linked in: mwl8k mac80211 cfg80211 [last unloaded: cfg80211]
As ieee80211_tx_info->control.sta may be NULL during ->tx call, avoiding sta
dereference in such scenario with the following patch.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Post commit e4eefec73e, the stack is
not generating the CCMP header for us anymore. This broke the CCMP
functionality since firmware was not doing this either. Set a flag
to tell the firmware to generate the CCMP header
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* remove interrupt.g inclusion from netdevice.h -- not needed
* fixup fallout, add interrupt.h and hardirq.h back where needed.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since firmware is capable of generating IV's for all crypto
suits (TKIP, CCMP and WEP), do not ask mac80211 to generate
IV when HW crypto is being used. Instead only reserve
appropriate space in tx skb's in the driver, so that the
firmware can write IV's values.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The WEP key length was being set to 0 erroneously which broke WEP support.
Fix the same by setting the key length appropriately.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The tx_headroom required for mwl8k driver is 32 bytes and it
can use the space for 802.11 header received from mac80211.
mwl8k considers the smallest 802.11 frame (CTS2self of 10
bytes) that can be received from mac80211 to compute the
extra_tx_headroom as 22 (32 - 10) bytes.
When the wireless interface is part of bridge, this
extra_tx_headroom requirement results in a memcpy in
mac80211 (in function pskb_expand_head) for all the data
frames needing L2 forwarding/bridging, when NET_SKB_PAD is
defined as 32. This patch reduces the extra_tx_headroom by
8 bytes so that memcpy of data frames in mac80211 is
avoided in this case.
The resize will be required in driver for frames with 802.11
header size of less than 18 bytes.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AFAICT, this driver is claiming that 24 bits of rate info fit into a
16-bit field in the Tx descriptor. Anyway, the use of bitfields is
frowned-upon for a variety of well-documented reasons...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tell the firmware to enable the life time expiry of tx packets
in the hardware. The hardware will now refer to the timestamp
in every tx packet and decide whether the packet needs to be
dropped or transmitted.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since queues are not stopped anymore, management frames would be
dropped if the corresponding tx queue is full.
This can cause issues say when we want to setup an ampdu stream and
action frames i.e addba requests keep getting dropped frequently.
Fix this by reserving some buffers to allow management frames to
go through in queue full conditions.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Timestamp tx packets using a HW micro-second timer.
This timestamp will be compared to the current timestamp
in the hardware and if the difference is greater than 500ms,
the packet will be dropped.
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is in preparation to support life time expiry of packets in the
hardware to avoid head-of-line blocking where a slow client can
hog a tx queue and affect the traffic to a faster client from the same
queue. Time stamp the packets in driver to allow dropping them in the
hardware if they are queued for more than 500ms.
If queues are stopped, packets will be queued up outside the driver.
Since we will be able to timestamp the packets only after they hit the
driver, the timestamp will be less accurate since we cannot consider
the time the packets spent in queues outside the driver. With this commit,
to achieve accurate timestamping, the tx queues will not be stopped in
normal conditions. The only scenarios where the queues will be stopped are
when firmware commands are executing or if the interface is brought down.
Now, we need to be prepared for a situation where packets hit the driver
even after the tx queues are full. Drop all such packets in the driver itself.
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, ampdu stream is created on the first qos packet to an
HT sta. The overhead of setting up the BA session may not be
justified if the outgoing packet rate is minimal (e.g., ping). So
we only allow ampdu streams after seeing a critical number of
packets in an arbitrary one-second interval.
Based on work by Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We do not need to enable all the interrupts in mwl8k_probe_hw.
We need to enable only MWL8K_A2H_INT_OPC_DONE interrupt for sending
commands to the firmware. Keep the other interrupts masked in
mwl8k_probe_hw. Also, in mwl8k_start, where we expect other interrupts,
enable only those interrupts we are interested in.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix checkpatch errors and warnings comprising of indent errors, spaces and
__packed warnings. Also fix 'make C = 2' warnings.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of configuring tx power unconditionally, check for
IEEE80211_CONF_CHANGE_POWER and configure it only when stack
sets this flag
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the mwl8k driver attempts and fails to switch from sta to ap
firmware (or vice-versa) in the mwl8k_add_interface routine, the
mwl8k_stop routine will be called. This routine must not attempt
to free the irq if it was not requested.
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Queue ADDBA requests in respective data queues to avoid ADDBA
requests and the the related data packets (to the same ra/tid)
queued in the hardware to be sent out asynchronously.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the outgoing packet rate to a particular HT station is <=6.5
Mbps, do not attempt to create an ampdu. Also, if the outgoing
rate is legacy rate, do not create an ampdu.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When an ampdu stream is on, if the firmware rate adaptation
logic decides that the outgoing packet rate to the station needs
to go below 6.5Mbps (non HT rate), it sends an event indicating that
the ampdu stream needs to be destroyed. Handle this event in the driver
and destroy the ampdu stream so that the rate can go below 6.5Mbps
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Specifically, handle ampdu_action and attempt to start a BA
session on receiving the first qos packet from mac80211 for
transmission to a HT sta. While the BA session is being created,
all the packets belonging to that stream will be dropped to
prevent sequence number mismatch at the recipient.
Contains contributions from:
Yogesh Powar <yogeshp@marvell.com>
Pradeep Nemavat <pnemavat@marvell.com>
Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In particular, we can now add, start, lookup, and remove streams.
Based on work by Nishant Sarmukadam <nishants@marvell.com> and
Pradeep Nemavat <pnemavat@marvell.com>.
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We now have two different kinds of queues. And the number of
AMPDU queues may vary. So we must be clear about which queues we
are dealing with. Note that when we report the number of queues
to mac80211, we only report the WMM queues.
Based on work by Yogesh Powar <yogeshp@marvell.com>.
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware APIv2 adds the following enhancements:
-- capabilities are reported by the firmware
-- API supports up to 8 dedicated AMPDU streams
-- optional packet timestamping and expiration can be enabled.
Specifically, packets that are queued in firmware for longer
than 500ms will be dropped if this option is used.
Based on work by "Nishant Sarmukadam" <nishants@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Specifically, APIv2 will specify a variable number of AMPDU
queues in the MWL8K_CMD_GET_HW_SPEC. So init the tx queues after
MWL8K_CMD_GET_HW_SPEC for ap fw.
Also, we make it safe to deinit queues that have not been init'd.
This happens if the mwl8k_get_hw_spec_ap routine fails, for
example.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use kcalloc or kzalloc rather than the combination of kmalloc and memset.
Thanks coccicheck for detecting this.
(http://coccinelle.lip6.fr/)
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The return value of the tx operation is commonly
misused by drivers, leading to errors. All drivers
will drop frames if they fail to TX the frame, and
they must also properly manage the queues (if they
didn't, mac80211 would already warn).
Removing the ability for drivers to return a BUSY
value also allows significant cleanups of the TX
TX handling code in mac80211.
Note that this also fixes a bug in ath9k_htc, the
old "return -1" there was wrong.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> [ath5k]
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> [rt2x00]
Acked-by: Larry Finger <Larry.Finger@lwfinger.net> [b43, rtl8187, rtlwifi]
Acked-by: Luciano Coelho <coelho@ti.com> [wl12xx]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All mwl8k parts perform rate control in firmware. Make this known to
mac80211 so that it does not launch minstrel. Also, because actual tx
rate information is not available from the firmware, invalidate the
rate status before returning the skb to mac80211.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When configuring rx antennas using CMD_RF_ANTENNA, the argument input is
the number of antennas to be enabled. For AP, we support 3 rx antennas
and hence set the field to 3. For tx antennas, value is a bitmap, so 0x7
enables all three.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.
This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.
The following drivers have been updated to reflect the API changes:
iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
The drivers have been compile-tested only.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: Brian Prodoehl <bprodoehl@gmail.com>
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The aggregation code currently doesn't implement the
buffer size negotiation. It will always request a max
buffer size (which is fine, if a little pointless, as
the mac80211 code doesn't know and might just use 0
instead), but if the peer requests a smaller size it
isn't possible to honour this request.
In order to fix this, look at the buffer size in the
addBA response frame, keep track of it and pass it to
the driver in the ampdu_action callback when called
with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
way the driver can limit the number of subframes in
aggregates appropriately.
Note that this doesn't fix any drivers apart from the
addition of the new argument -- they all need to be
updated separately to use this variable!
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
set_key callback is defined for mac80211 to install keys for HW crypto in AP
mode. Driver currently falls back to SW crypto in STA mode. Add support to
configure the keys appropriately in the hardware after the set_key routine is
called.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When hw crypto is enabled, set rx status flags appropriately depending on
whether hw crypto is enabled for a particular bss.
Also report MIC errors to mac80211, so that counter measures can be
initiated
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: yogesh powar <yogeshp@marvell.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Different tail pads will be needed for crypto depending on the crypto
mode. Add support to encapsulate the packets with appropriate pad
value.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add capability to add_dma_header to support padding at tail of the data
packet to be transmitted when crypto is enabled. Padding is required for
adding crypto information in data packets for supporting 802.11 security
modes.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This eliminates compiler warnings by doing things how the
firmware class expects.
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Introduce a firmware loading state machine to manage the process
of loading firmware asynchronously and completing initialization
upon success. The state machine attempts to load the preferred
firmware image. If that fails, and if an alternative firmware
image is available, it will attempt to load that one.
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AP firmware specifies an API version in the GET_HW_SPEC
command response. Currently, the driver only supports AP
firmware for the 8366, and only supports API v1. In the future,
if higher API version firmwares emerge (possibly for different
chips), different ops can be selected based on the reported API
version.
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The mwl8k can operate in AP or STA mode, depending on the
firmware image that is loaded. By default, STA firmware is
loaded. Allow the user to override this default mode at
module load time. This saves an unnecessary firmware reload
for users only interested in AP mode.
Also, the firmware image can be swapped to meet the user's
add_interface request. For example, suppose the STA
firmware is loaded, no STA interface has been added, and the
user adds an AP interface. In this case, the AP firmware
will be loaded to meet the request.
Based on contributions from Pradeep Nemavat <pnemavat@marvell.com>,
Yogesh Powar <yogeshp@marvell.com>, and
Lennert Buytenhek <buytenh@wantstofly.org>.
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is in preparation for supporting different fw images for
different interface types, and for supporting asynchronous
firmware loading.
Based on a patch from Pradeep Nemavat <pnemavat@marvell.com>
and Yogesh Powar <yogeshp@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
APIv1 AP firmware does not support the RF_TX_POWER command. It
supports the similar TX_POWER command.
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts change 783391c443728febc669e40597193308460e7b4f.
The stabilized AP v1 firmware uses the same tx descriptor as
the STA firmware.
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AP firmware uses xmitcontrol to differentiate between AMPDU
and non-AMPDU frames. As the support for AMPDU is not yet
added, set xmitcontrol to non-AMPDU for all tx frames for AP
firmware. This field will be set to indicate ampdu/non-ampdu
frames when tx AMPDU support is added.
Signed-off-by: Pradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: Brian Cavagnolo <brian@cozybit.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit c96c31e499
"(drivers/net/wireless: Use wiphy_<level>)"
inadvertently changed some upper case words to
lower case. Restore the original case.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:1541:21: expected restricted __le16 [usertype] result
drivers/net/wireless/mwl8k.c:1541:21: got int
drivers/net/wireless/mwl8k.c:1575:42: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1575:42: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1587:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1587:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1592:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1592:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1845:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1845:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1848:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1851:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1854:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1857:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1860:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:3055:20: expected restricted __le16 [usertype] ht_caps
drivers/net/wireless/mwl8k.c:3055:20: got unsigned short [unsigned] [usertype] cap
At least the last one looks like a real bug...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
cleanup patch.
Use new __packed annotation in drivers/net/
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The DMA API is preferred.
No functional change.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (37 commits)
smc91c92_cs: fix the problem of "Unable to find hardware address"
r8169: clean up my printk uglyness
net: Hook up cxgb4 to Kconfig and Makefile
cxgb4: Add main driver file and driver Makefile
cxgb4: Add remaining driver headers and L2T management
cxgb4: Add packet queues and packet DMA code
cxgb4: Add HW and FW support code
cxgb4: Add register, message, and FW definitions
netlabel: Fix several rcu_dereference() calls used without RCU read locks
bonding: fix potential deadlock in bond_uninit()
net: check the length of the socket address passed to connect(2)
stmmac: add documentation for the driver.
stmmac: fix kconfig for crc32 build error
be2net: fix bug in vlan rx path for big endian architecture
be2net: fix flashing on big endian architectures
be2net: fix a bug in flashing the redboot section
bonding: bond_xmit_roundrobin() fix
drivers/net: Add missing unlock
net: gianfar - align BD ring size console messages
net: gianfar - initialize per-queue statistics
...
Converts the list and the core manipulating with it to be the same as uc_list.
+uses two functions for adding/removing mc address (normal and "global"
variant) instead of a function parameter.
+removes dev_mcast.c completely.
+exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
manipulation with lists on a sandbox (used in bonding and 80211 drivers)
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
This converts mwl8k to use the new station
add/remove callbacks instead of using the
old sta_notify callback.
The new callbacks can sleep, so a lot of
code can be removed now.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use spin_[un]lock_bh in mwl8k_sta_notify(). The sta_notify handler is
required to be atomic, yet it can be called in process context, so make
sure one call won't preempt another.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
get_tx_stats() will be removed from mac80211.
mwl8k used struct ieee80211_tx_queue_stats internally to track the queue
lenght. Replace struct ieee80211_tx_queue_stats with a simple len field
in struct mwl8k_tx_queue. Limit and count fields seemed to be unused.
Compile-tested only.
Cc: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Because DTIM information is required for powersave
but is only conveyed in beacons, wait for a beacon
before enabling powersave, and change the way the
information is conveyed to the driver accordingly.
mwl8k doesn't currently seem to implement PS but
requires the DTIM period in a different way; after
talking to Lennert we agreed to just have mwl8k do
the parsing itself in the finalize_join work.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As follows:
- GET_HW_SPEC is now responsible for setting
priv->{ap,sta}_macids_supported, which are bitmasks of supported
macids for AP and STA mode. (Typically, STA firmware images will
support only one macid, #0, in STA mode, and AP firmware images
will support macids #0-7, in AP mode.)
- Our wiphy ->interfaces_modes is now set based on the non-zero-ness
of these two bitmasks.
- We main priv->macids_used, a bitmask of which macids are currently
in use. ->add_interface() will assign the lowest free macid for
this interface type as it is created, or bail out if there are no
more free macids to assign. ->delete_interface() will mark the
macid as being free again.
This enables the multi-BSS code added in the previous commits.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
SET_BEACON, SET_MAC_ADDR, BSS_START and SET_NEW_STN are the currently
supported firmware commands that are actually per-vif commands. Use
mwl8k_post_pervif_cmd() for these commands, so that the macid of the
vif they operate on gets passed down into the firmware.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
One of the bytes in the mwl8k firmware command header is the 'macid'
byte, which for per-vif commands indicates which of the BSSes this
command is intended for. (For commands that are not per-vif commands,
this byte can just be 0.)
This patch adds mwl8k_post_pervif_cmd(), which will take the macid
assigned to this interface (to be done in ->add_interface()), copy it
into the command packet macid field, and post the command as usual.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To prepare for adding multi-BSS support.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make the decision about whether to register the 2.4 and 5 GHz bands
with mac80211 by looking at the capability field in GET_HW_SPEC (STA
firmware only for now). This enables 5 GHz STA operation.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Whenever mac80211 gives us a legacy rate bitmap in the context of the
5 GHz band, we need to remember to shift the bitmap left by 5 positions
before giving it to the firmware, as the firmware follows the bitmap
bit assignment of the 2.4 GHz rate table even if we're on the 5 GHz
band, and the 2.4 GHz rate table includes five non-OFDM rates at the
start that are not valid in the 5 GHz band.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The mwl8k firmware uses indices into the 2.4 GHz band rate table for
the receive descriptor channel field even if the packet was received
on a 5 GHz channel, while mac80211 expects an index into the 5 GHz
band rate table when packets are received on the 5 GHz band, which
presents a mismatch as the 5 GHz band rate table lacks the five
non-OFDM rates that the 2.4 GHz rate table starts with.
To handle this properly, we need to substract 5 from the rate index
field if the packet was received on a 5 GHz channel (and was not
received at an MCS rate).
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
So that we can make 2.4 GHz and 5 GHz band registration conditional
on the capability bitmask returned by the firmware.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To prepare for adding 5 GHz band/channels/rates.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
0x2a43 is a single-band (2.4GHz only) 88w8366 mini-PCIe card.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
By storing the sequence counter in << 4 format, like other drivers do.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add MODULE_FIRMWARE tags for the mwl8k firmware images that don't
have them yet, and move them to where the firmware image names are
declared.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Like how TX reclaim is done in a tasklet, move receive processing
to tasklet context as well. This can have nice benefits for CPU
utilisation and throughput, especially at 3-stream rates.
(Use the same CLEAR_SEL trick as the TX reclaim tasklet does, to
avoid having to touch the interrupt mask registers.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
By making use of the CLEAR_SEL feature of the mwl8k host interface
interrupt controller, we can keep the TX_DONE interrupt source masked
while the transmit reclaim tasklet is running (NAPI style) without
having to touch the interrupt controller's interrupt mask register
when entering or exiting polling mode, and without having to do any
more register reads/writes than we do now.
When CLEAR_SEL is enabled on the TX_DONE interrupt source, reading
the interrupt status register will clear the TX_DONE status bit if
it was set, allowing it to be set again if a new TX_DONE event arrives
while we are running the TX reclaim tasklet, but such a new event will
then not trigger another PCI interrupt until a zero is written to the
TX_DONE interrupt status register bit.
I.e., if we write a zero to the TX_DONE interrupt source bit in the
interrupt status register when the TX reclaim tasklet thinks it's
done, a PCI interrupt will be triggered if a new TX_DONE event arrived
from the hardware between us deciding that there is no more work to do
and re-enabling the TX_DONE interrupt source, thereby avoiding the
classic NAPI poll mode exit race that would otherwise occur.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add a limit argument to mwl8k_txq_reclaim(), to allow limiting the
number of packets that it will reclaim, and make it return the number
of packets that it reclaimed.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add support for creating AP interfaces, and enabling beaconing.
This allows running a basic AP (11b/g mode only for now).
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
STA firmware uses UPDATE_STADB to manipulate the hardware station
database, whereas AP firmware uses SET_NEW_STN -- this implements the
latter, and hooks it into mwl8k_sta_notify(), to be used if we're
running on AP firmware.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As with the STA version, unicast will use auto rate adaptation, but
the AP version allows setting the rates to be used for management and
multicast transmissions, which can be set based on the BSS basic rate
set.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As we always use the auto rate adaptation feature and never pass in
a rate table, USE_FIXED_RATE can be simplified somewhat. While we're
at it, rename it to *_sta, as this is the STA version of the command.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While it is reasonable to expect that at least one transmit ring entry
will be processed per second while we are waiting for the transmit
rings to drain, the firmware can end up doing batching of transmit ring
status writeback, which means that the transmit rings can appear stuck
for more than a second at a time.
Bump the TX drain wait timeout up from 1 to 5 seconds to account for
this.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The comment and code in mwl8k_cmd_set_edca_params() suggest that the
mapping between SET_EDCA_PARAMS queue numbers and transmit rings isn't
actually 1:1, while tests show that the mapping is in fact 1:1. So,
get rid of the transmit queue 0/1 swapping.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
