- 09 Nov, 2011 40 commits
-
-
Amitkumar Karwar authored
By default SDIO multiport aggregation is disabled. It's useful to get good throughput results. This patch enables it. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
We dereference adapter in the error handling code so this needed to be fixed. This function is always called like: adapter->if_ops.host_to_card(adapter, ...); so adapter can never be NULL and I've removed the NULL check. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
Dan Carpenter authored
The previous if statement means this that pointer is NULL so there is no need to free it. Signed-off-by:
-
Julia Lawall authored
Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc. A semantic patch rule for the kstrtoul case is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression a,b; {int,long} *c; @@ -strict_strtoul +kstrtoul (a,b,c) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Julia Lawall authored
Use kstrtoul, etc instead of the now deprecated strict_strtoul, etc. A semantic patch rule for the kstrtoul case is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression a,b; {int,long} *c; @@ -strict_strtoul +kstrtoul (a,b,c) // </smpl> Signed-off-by:
-
Johannes Berg authored
Implement the socket wifi TX status error queue reflection in mac80211. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
The new wifi socket TX capability should be supported by wifi drivers, let them advertise whether they do or not. Signed-off-by:
-
Helmut Schaa authored
Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
-
Franky Lin authored
Prepare for adding backplane interconnect type support Reviewed-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
Franky Lin <frankyl@broadcom.com> Signed-off-by:
-
Franky Lin authored
Use SSB macros in order to clean up brcmfmac code Reviewed-by:
-
Franky Lin authored
This patch is part of the abstracting chip backplane handle code series. Reviewed-by:
-
Franky Lin authored
This patch is part of the abstracting chip backplane handle code series. Reviewed-by:
-
Franky Lin authored
This patch is part of the abstracting chip backplane handle code series. Reviewed-by:
-
Franky Lin authored
Prepare for adding backplane interconnect type support Reviewed-by:
-
Franky Lin authored
Prepare for adding backplane interconnect type support Reviewed-by:
-
Franky Lin authored
Merged brcmf_sdbrcm_chip_attach into brcmf_sdio_chip_attach for better readability. Reviewed-by:
-
Franky Lin authored
Same register writes have been done in brcmf_sdbrcm_probe_init which is earlier in the same code path. Reviewed-by:
-
Franky Lin authored
This patch is part of the abstracting chip backplane handle code series. Reviewed-by:
-
Franky Lin authored
This will provide a better code flow that fits the logic Reviewed-by:
-
Franky Lin authored
This patch is part of the abstracting chip backplane handle code series. Reviewed-by:
-
Franky Lin authored
This patch is part of the abstracting chip backplane handle code series. Reviewed-by:
Roland Vossen <rvossen@broadcom.com> Signed-off-by:
-
Franky Lin authored
This patch is part of abstracting chip backplane handle code series. Reviewed-by:
-
Franky Lin authored
Currently backplane handle code is scatterd around dhd_sdio.c which is not good for maintenance and adding new backplane interconnect type support. This patch and the follow up patches are going to abstract all chip backplane control code specific for sdio bus into this new sdio_chip.c Reviewed-by:
-
Franky Lin authored
4329 with chiprev 0 can not be found on any product. The code can be removed. Reviewed-by:
-
Johannes Berg authored
For probe responses it can be useful to not wait for ACK to avoid retransmissions if the station that sent the probe is already on the next channel, so allow userspace to request not caring about the ACK with a new nl80211 flag. Since mac80211 needs to be updated for the new function prototype anyway implement it right away -- it's just a few lines of code. Signed-off-by:
-
Johannes Berg authored
Implement the cfg80211 notification but only send one event per associated station to avoid having tons of events if the station thinks it should be allowed to use 4addr frames but it isn't. Signed-off-by:
-
Johannes Berg authored
The frames are used by AP/STA WDS mode, and hostapd needs to know when such a frame was received to set up the VLAN appropriately to allow using it. Signed-off-by:
-
Johannes Berg authored
If there's an interface in AP mode, OBSS beacons are needed by hostapd/wpa_s to implement logic to enable/disable protection etc. Report the frames and set the capability flag. Signed-off-by:
-
Johannes Berg authored
Add the ability to register to received beacon frames to allow implementing OLBC logic in userspace. The registration is per wiphy since there's no point in receiving the same frame multiple times. Signed-off-by:
-
Johannes Berg authored
Support probing clients with null data frames in AP mode. Signed-off-by:
-
Johannes Berg authored
When the AP SME in hostapd is used it wants to probe the clients when they have been idle for some time. Add explicit API to support this. Signed-off-by:
-
Johannes Berg authored
Add the ability to advertise that the device contains the AP SME and what features it can support. There are currently no features in the bitmap -- probe response offload will be advertised by a few patches Arik is working on now (who took over from Guy Eilam) and a device with AP SME will typically implement and require response offload. Signed-off-by:
-
Johannes Berg authored
Add support for the spurious class3 frame event to mac80211 to enable AP w/o monitor mode. Signed-off-by:
-
Johannes Berg authored
To implement AP mode without monitor interfaces we need to be able to send a deauth to stations that send frames without being associated. Enable this by adding a new nl80211 event for such frames that an application can subscribe to. Signed-off-by:
-
Johannes Berg authored
This will allow us to support dynamic WEP with 802.1X properly in mac80211 by not encrypting outgoing and accepting unencrypted incoming frames. Signed-off-by:
-
Johannes Berg authored
Drivers that need to drop a frame before it can be transmitted will usually simply free that frame. This is currently fine, but in the future it'll be needed to tell mac80211 about this case, so add a new routine that frees a TX skb. Signed-off-by:
-
Javier Cardona authored
We only need to set the skb queue twice: 1. by the netdev, on local TX. 2. when forwarding a mesh frame. We only need to set the qos header twice: 1. by mac80211, on local TX. 2. when putting a frame on the mpath->frame_queue We also don't need the RA in order to set the proper queue mapping since all mesh STAs are QoS, indicate this and do it once when the frame is received. Also fixes an issue where the QoS header and queue mapping was not set for unicast forwarded frames. Signed-off-by:
Javier Cardona <javier@cozybit.com> Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> Signed-off-by:
-
Thomas Pedersen authored
There was an an implicit assumption that any QoS data frame received from a STA/TID with an active BA session was sent to this vif as part of a BA. This is not true if IFF_PROMISC is enabled and the frame was destined for a different peer, for example. Don't treat these frames as part of a BA from the sending STA. Signed-off-by:
-
Thomas Pedersen authored
Previously QoS multicast frames had the Normal Acknowledgment QoS control bits set. This would cause broadcast frames to be discarded by peers with which we have a BA session, since their sequence number would fall outside the allowed range. Set No Ack QoS control bits on multicast QoS frames and filter these in de-aggregation code. Signed-off-by:
-
Javier Cardona authored
Don't accept redundant PREQs for a given destination. This fixes a problem under high load: kernel: [20386.250913] mesh_queue_preq: 235 callbacks suppressed kernel: [20386.253335] Mesh HWMP (mesh0): PREQ node queue full kernel: [20386.253352] Mesh HWMP (mesh0): PREQ node queue full (...) The 802.11s protocol has a provision to limit the rate of path requests (PREQs) are transmitted (dot11MeshHWMPpreqMinInterval) but there was no limit on the rate at which PREQs were being queued up. There is a valid reason for queuing PREQs: this way we can even out PREQ bursts. But queueing multiple PREQs for the same destination is useless. Reported-by:
Pedro Larbig <pedro.larbig@carhs.de> Signed-off-by:
-
