Currently cfg80211 fails to create a "phy80211" symlink in sysfs from
the net device to the wiphy device. The latter needs to be registered
first.
Compile-tested only.
Reported-by: Cesare Leonardi <celeonar@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RFCSR is only used in rt2800. For other chipsets, the debug struct
for rfcsr should be zeroed, which isn't be an issue, since the code
can now cope with that.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Allow a register to be unspecified, therefore not creating its debugfs
file entry.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"oui_type" in structure "ieee_types_vendor_header" is not used separately,
so include it in "oui" array. Now complete oui will be compared fixing
following warnings.
drivers/net/wireless/mwifiex/sta_ioctl.c:1410 mwifiex_set_gen_ie_helper()
error: memcmp() 'pvendor_ie->oui' too small (3 vs 4)
drivers/net/wireless/mwifiex/sta_ioctl.c:1435 mwifiex_set_gen_ie_helper()
error: memcmp() 'pvendor_ie->oui' too small (3 vs 4)
drivers/net/wireless/mwifiex/scan.c:1177 mwifiex_update_bss_desc_with_ie()
error: memcmp() 'vendor_ie->vend_hdr.oui' too small (3 vs 4)
drivers/net/wireless/mwifiex/scan.c:1185 mwifiex_update_bss_desc_with_ie()
error: memcmp() 'vendor_ie->vend_hdr.oui' too small (3 vs 4)
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is a cut and paste mistake, sizeof(struct mib_local) was intended
instead of sizeof(struct mib_phy). The call to at76_get_mib() uses
sizeof(struct mib_local) correctly, although I changed that to
sizeof(*m) for style reasons after discussion with some of the wireless
maintainers.
The current code works fine because mib_phy structs are larger than
mib_local structs. But we may as well clean it up.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are various problems happened on 5GHz band not observed on
2.4 GHz (microcode errors, queue stuck, etc... ) . Also roaming
between 5GHz AP and 2GHz does not work very well. To workaround
the problems add option to disable 5GHz support. This will help
on environments where APs are dual-band, and devices will not try
to associate on band where issues happen.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Also remove a debug print when allocation error occurred.
The kernel will complain anyway.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
When bluetooth coex is active and certain condition matched,
driver need to decide should the tx power been reduce or not.
Adding the logic to manage it.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Do not assume we have our subsystem including this for us,
at least for older kernels this is not true. Lets just be
explicit about this requirement for the usage of wake_up().
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Conflicts:
drivers/net/ethernet/intel/e1000e/param.c
drivers/net/wireless/iwlwifi/iwl-agn-rx.c
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
drivers/net/wireless/iwlwifi/iwl-trans.h
Resolved the iwlwifi conflict with mainline using 3-way diff posted
by John Linville and Stephen Rothwell. In 'net' we added a bug
fix to make iwlwifi report a more accurate skb->truesize but this
conflicted with RX path changes that happened meanwhile in net-next.
In e1000e a conflict arose in the validation code for settings of
adapter->itr. 'net-next' had more sophisticated logic so that
logic was used.
Signed-off-by: David S. Miller <davem@davemloft.net>
Send the EAPOL and management frames in the same AC_VO queue. The issue
happens when the AP supports QOS, the management frames are sent to AC_VO
queue and EAP frame goes to AC_BE queue. Even though the EAP frame is
queued before the DEAUTH management frame, as they are queued on different
h/w queues, order of delivery between these frames cannot be controlled.
This fixes the connection failure seen in P2P case.
Signed-off-by: Vivek Natarajan <nataraja@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
By default, iwlwifi uses order-1 pages (8 KB) to store incoming frames,
but doesnt say so in skb->truesize.
This makes very possible to exhaust kernel memory since these skb evade
normal socket memory accounting.
As struct ieee80211_hdr is going to be pulled before calling IP stack,
there is no need to use dev_alloc_skb() to reserve NET_SKB_PAD bytes.
alloc_skb() is ok in this driver, allowing more tailroom.
Pull beginning of frame in skb header, in the hope we can reuse order-1
pages in the driver immediately for small frames and reduce their
truesize to the minimum (linear skbs)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Neal Cardwell <ncardwell@google.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit a844adfd7b.
The commit a844adfd is degrading rx sensitivity of lower rate in
HT40 mode and it is confirmed that reverting the change is
improving rx sensitivity.
spur_freq_sd (for self-corr in AGC) is defined with respect to the
center of each 20MHz channel while spur_phase_delta (for self-corr
in Rx and spur data filter) is defined with respect to the center
of current RF channel.
So in short, we need to subtract spur_freq_sd (for self-corr in AGC)
by the offset between the center of primary20 and the center of RF
channel in SW. This offset could be +/10 MHz for dynamic 40.
Cc: Madhan Jaganathan <madhanj@qca.qualcomm.com>
Signed-off-by: Kai Shi <kaishi@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
dpc_tl_lock is not acquired in the error handle code for bus down.
But it's unlocked using spin_unlock_irqrestore after finishing task
list walk down. Grab the lock before breaking the loop to avoid a
double unlock.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Return status of ath6kl_htc_tx_issue() is ignored in
ath6kl_htc_tx_from_queue(), but failed tx packet is
is not cleaned up. To fix memory leak in this case, call
completion with error. Also, throw an error debug message
when tx fails in ath6kl_sdio_write_async() due to shortage
in bus request buffer.
kvalo: change the error message to WARN_ON_ONCE()
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There are few cases where the tx skb is dropped but netstats is
not updated, fix this.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This driver currently leaves elp_work behind when stopping, which
occasionally results in data corruption because work function ends
up accessing freed memory, typical symptoms of this are various
worker_thread crashes. Fix it by cancelling elp_work.
Cc: stable@vger.kernel.org # v2.6.37+
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently SDIO glue frees it's own structure before calling
wl1251_free_hw(), which in turn calls ieee80211_unregister_hw().
The later call may result in a need to communicate with the chip
to stop it (as it happens now if the interface is still up before
rmmod), which means calls are made back to the glue, resulting in
freed memory access.
Fix this by freeing glue data last.
Cc: stable@vger.kernel.org # v2.6.37+
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 2a19032 (b43: reload phy and bss settings after core restarts)
introduced an unconditional call to b43_op_config() at the end of
b43_op_start(). When firmware fails to load this can wedge the system.
There's no need to reload the configuration after a failed
initialization anyway, so only make the call if initialization was
successful.
BugLink: http://bugs.launchpad.net/bugs/950295
Cc: Felix Fietkau <nbd@openwrt.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"iwlwifi: use correct released ucode version" change
the ucode api ok from 6000G2 to 6000G2B, but it shall belong
to 6030 device series, not the 6005 device series. Fix it
Cc: stable@vger.kernel.org #3.3+
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When our driver device is removed on the AHB bus, our IO memory is never unmapped.
Signed-off-by: Jonathan Bither <jonbither@gmail.com>
Reviewed-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
dpc takes care of all data packets transmissions for sdio function
2. It is possible that it misses some completion events when the
traffic is heavy or it's running on a slow cpu. A linked list is
introduced to make sure dpc is invoked whenever needed.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
SDIO stack doesn't have a structure for function 0. The structure
pointer stored in card->sdio_func[0] is actually for function 1.
With current implementation the register read/write is applied to
function 1. This pathch fixes the issue.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Reviewed-by: Florian Fainelli <florian@openwrt.org>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On the htc mbox layer, it will assign each endpoint (AC) with a
different Tx-packet-drop threshold, so lower priority AC is more
likely to drop packets and the cookies become more available to higher
priority AC.
On the htc pipe layer, assign the tx packet drop threshold as well, it
will let AC to drop packets when cookies below the tx packet drop
threshold.
Signed-off-by: Kevin Fang <kevin.fang@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
When a STA sends huge BK QoS data frame first and then sends BE/VI/VO
QoS data frame, the corresponding throughput becomes much lower than
that without sends BK QoS data frame before.
The root cause is that when station send BK stream, the tx credits of
BK stream don't return back to higher priority QoS stream such as BE,
VI, and VO stream. This patch will handle BK stream properly, when
there is higher priority QoS stream, it will seek tx credits from BK
stream properly.
Signed-off-by: Kevin Fang <kevin.fang@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
bss filter is configured to allow the frames from all the bss other
than the currenly connected one, this is done when a scan is requested
in connected state. There is no reason to filter out the currently
connected bss, configure the filter to allow all the bss. This would
fix the reporting of stale rssi of the current bss while scanning.
Reported-by: Naveen singh <navesing@qca.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
With firmwares which do not support rsn capability override
(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE) from host would
cause 4-way handshake failure when HT cap is advertised.
To fix this, do not advertise HT cap with cfg80211 for
those fw.
kvalo: fix a checkpatch warning
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This patch enables all multicast packets in non suspend mode
and enable multicast filtering in wow suspend mode. This also
fixes a bug in multicast where the driver assumed disable
multicast-all command disabled/filtered all multicast
packets, which was wrong assumption, because firmware will
apply the programmed filter.
Multicast requirements
- Enable forward all multicast packets(no filtering) in
non suspend mode.
- Enable multicast filtering in wow suspend mode for both
AP and CLIENT.
kvalo: fix a checkpatch warning and drop unrelated newline removal
Signed-off-by: Naveen Gangadharan <ngangadh@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
err() was a very old USB-specific macro that I thought had
gone away. This patch removes it from being used in the
driver and uses dev_err() instead.
CC: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The patch "ath6kl: support fw reporting phy capabilities" gave the
firmware the ability to disable certain wiphy supported bands. Check if
this is the case in ath6kl_wmi_beginscan_cmd to avoid dereferencing a
NULL pointer.
kvalo: change the patch so that there's no code between declarations
Signed-off-by: Thomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* PS_WAIT_FOR_TX_ACK is used in network-sleep mode and checking
it for handling IDLE transitions is incorrect. Fix this.
* RX PCU/DMA engines have to be stopped before setting the chip into
full-sleep mode - otherwise the chip becomes mute.
* Make things a bit clear by checking explicitly for network-sleep
mode in the tx() routine and add a couple of debug statements
to aid PS debugging.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Newer devices have 20 (5000 series) or 30 (6000 series)
hardware queues, rather than the 16 that 4965 had. This
was added to the driver a long time ago, but improperly:
the queue registers for the higher queues aren't just
continuations of the registers for the first 16 queues,
they are in other places. Therefore, the hardware would
lock up when trying to activate queue 16 or above and
the device would have to be restarted.
Thanks goes to Emmanuel who identified this and told me
how the queue programming should be done.
Note that we don't use queues 20 and higher today and
doing so needs more work than this.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix merge between commit 3adadc08cc ("net ax25: Reorder ax25_exit to
remove races") and commit 0ca7a4c87d ("net ax25: Simplify and
cleanup the ax25 sysctl handling")
The former moved around the sysctl register/unregister calls, the
later simply removed them.
With help from Stephen Rothwell.
Signed-off-by: David S. Miller <davem@davemloft.net>
