Conflicts:
net/mac80211/sta_info.c
net/wireless/core.h
Two minor conflicts in wireless. Overlapping additions of extern
declarations in net/wireless/core.h and a bug fix overlapping with
the addition of a boolean parameter to __ieee80211_key_free().
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
an 802.3 frame. Frames with a lower value in the ethernet type field
are Ethernet II.
Also update all the users of this value that David Miller and
I could find to use the new constant.
Also correct a bug in util.c. The comparison with ETH_P_802_3_MIN
should be >= not >.
As suggested by Jesse Gross.
Compile tested only.
Cc: David Miller <davem@davemloft.net>
Cc: Jesse Gross <jesse@nicira.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Bart De Schuymer <bart.de.schuymer@pandora.be>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org
Cc: bridge@lists.linux-foundation.org
Cc: linux-wireless@vger.kernel.org
Cc: linux1394-devel@lists.sourceforge.net
Cc: linux-media@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: dev@openvswitch.org
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calculating "offset" for final RSSI calibration we're using numbers
bigger than s8 can hold. We have for example:
offset[j] = 232 - poll_results[j];
formula. If poll_results[j] is small enough (it usually is) we treat
number's bit as a sign bit. For example 232 - 1 becomes:
0xE8 - 0x1 = 0xE7, which is not 231 but -25.
This code was introduced in e0c9a0219a
and caused stability regression on some cards, for ex. BCM4322.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
il4965_rs_initialize_lq checks to see if sta is null, however, before that
check il4965_rs_use_green dereferences sta when intializing use_green.
Avoid a potential null pointer dereference error by only calling
il4965_rs_use_green after we are sure sta is not null.
Smatch analysis:
drivers/net/wireless/iwlegacy/4965-rs.c:2160 il4965_rs_initialize_lq() warn:
variable dereferenced before check 'sta' (see line 2155)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The following issue was reported.
WARNING: at net/mac80211/util.c:599 ieee80211_can_queue_work.isra.7+0x32/0x40 [mac80211]()
Hardware name: iMac12,1
queueing ieee80211 work while going to suspend
Pid: 0, comm: swapper/0 Tainted: PF O 3.8.2-206.fc18.x86_64 #1
Call Trace: Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642992] <IRQ>
[<ffffffff8105e61f>] warn_slowpath_common+0x7f/0xc0
[<ffffffffa0581420>] ? ath_start_rx_poll+0x70/0x70 [ath9k]
<ffffffff8105e716>] warn_slowpath_fmt+0x46/0x50
[<ffffffffa045b542>] ieee80211_can_queue_work.isra.7+0x32/0x40
Fix this by avoiding to queue the work if our device has
already been marked as suspended or stopped.
Reported-by: Parag Warudkar <parag.lkml@gmail.com>
Tested-by: Parag Warudkar <parag.lkml@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Intermittently, b43 will report "Out of order TX status report on DMA ring".
When this happens, the driver must be reset before communication can resume.
The cause of the problem is believed to be an error in the closed-source
firmware; however, all versions of the firmware are affected.
This change uses the observation that the expected status is always 2 less
than the observed value, and supplies a fake status report to skip one
header/data pair.
Not all devices suffer from this problem, but it can occur several times
per second under heavy load. As each occurence kills the unmodified driver,
this patch makes if possible for the affected devices to function. The patch
logs only the first instance of the reset operation to prevent spamming
the logs.
Tested-by: Chris Vine <chris@cvine.freeserve.co.uk>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We're using "mind" variable to find the VCM that got the best polling
results. For each VCM we calculte "currd" which is compared to the
"mind". For PHY rev3+ "currd" gets values around 14k-40k. Looking for a
value smaller than 40 makes no sense, so increase the initial value.
This fixes a regression introduced in 3.4 by commit:
e0c9a0219a
(my BCM4322 performance dropped from 18,4Mb/s to 9,26Mb/s)
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit b6fc28a158.
This commit is reported to cause a regression in the support for some
revisions of 4313 ePA devices.
http://marc.info/?l=linux-wireless&m=136360340200943&w=2
Conflicts:
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the CONFIG_PM_SLEEP is enabled.
drivers/net/wireless/iwlegacy/common.c:4894:1: warning: 'il_pci_suspend' defined but not used [-Wunused-function]
drivers/net/wireless/iwlegacy/common.c:4912:1: warning: 'il_pci_resume' defined but not used [-Wunused-function]
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch is a bug fix for an issue wherein power save was not
working for PCIe. This happens because for processing power save
sleep confirm command we pull skb so that skb->data points ahead
of interface header. We use same skb to get other cmda responses
as well. So if we don't push skb after processing cmd response,
it results into reduction in skb->len and finally skb->len reaches
zero. This causes failure in processing sleep command response.
Fix this by pushing skb by INTF_HEADER_LEN at the end of command
response processing.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pull to get the thermal netlink multicast group name fix, otherwise
the assertion added in net-next to netlink to detect that kind of bug
makes systems unbootable for some folks.
Signed-off-by: David S. Miller <davem@davemloft.net>
My new tracing code for ath6kl introduced these warnings on 64-bit:
trace.h:38:1: warning: format '%d' expects argument of type 'int',
but argument 4 has type 'size_t' [-Wformat]
trace.h:61:1: warning: format '%d' expects argument of type 'int',
but argument 4 has type 'size_t' [-Wformat]
trace.h:84:1: warning: format '%d' expects argument of type 'int',
but argument 6 has type 'size_t' [-Wformat]
trace.h:119:1: warning: format '%d' expects argument of type 'int',
but argument 7 has type 'size_t' [-Wformat]
trace.h:173:1: warning: format '%d' expects argument of type 'int',
but argument 3 has type 'size_t' [-Wformat]
trace.h:193:1: warning: format '%d' expects argument of type 'int',
but argument 5 has type 'size_t' [-Wformat]
trace.h:221:1: warning: format '%d' expects argument of type 'int',
but argument 5 has type 'size_t' [-Wformat]
Fix them by using %zd.
Reported-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is a race between the restart flow and the workers.
The workers are cancelled after the fw is already killed
and might send HCMD when there is fw to handle them.
Simply check that there is a fw to which the HCMD can be
sent before actually sending it.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We didn't update the internal of the PCIe transport when
we read the RFkill state directly. Fix that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As reported by Ben Hutchings, there was a harmless issue in
the checks being done on the lengths of the TBs while
building the TFD for a multi-TB host command.
Cc: stable@vger@kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Based on:
RT5592_IQCalibration()
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/cips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enable support to 5592 chip.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
TXWI_STRUC
RXWI_STRUC
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/include/chip/rtmp_mac.h
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipAGCAdjust()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_RTMPAGCInit()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
AsicBBPWriteWithRxChain()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rtmp_chip.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes order of initialization of various registers similar like
on vendor driver.
Based on:
NICInitializeAsic()
RT5592LoadRFNormalModeSetup()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chip/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
GetIQCalibration()
IQCalibration()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rtmp_chip.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipSwitchChannel()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipSwitchChannel()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
InitFrequencyCalibrationMode()
RT5592_ChipCap
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/frq_cal.c
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592LoadRFNormalModeSetup()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592LoadRFNormalModeSetup()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592RFRegisters()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592RFRegisters()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592RFRegisters()
RF5592Reg_2G_5G[]
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
This patch also merge common frequency adjustment (RF_R17 settings)
code. Further work is needed, to setup more RF/BBP/MAC registers after
that.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add BBP registers initialization common with other chipsets, but for now
performed only for 5592.
Based on:
NICInitBBP()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592BbpRegisters()
NICInitBBP()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
NICInitRT5592MacRegisters()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
On vendor driver we do not initialize TX_SW_CFG{1,2}. However the same
difference is between rt2x00 and vendor driver for 5390 chip.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipSwitchChannel()
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on:
RT5592_ChipSwitchChannel()
RT5592_Frequency_Plan_Xtal20M[]
RT5592_Frequency_Plan_Xtal40M[]
from:
DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5592.c
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add basic defines for 5592 chip. It can not be enabled until
CONFIG_RT2800USB_RT55XX configuration option will be provided in the
Kconfig.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In case the spec->channels was not specified, print warning instead
of hard crash the kernel.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2800 hardware sometimes reorders tx frames when transmitting to
multiple BA enabled STAs concurrently.
For example a tx queue
[ STA1 | STA2 | STA1 | STA2 ]
can result in the tx status reports
[ STA1 | STA1 | STA2 | STA2 ]
when the hw decides to put the frames for STA1 in one AMPDU.
To mitigate this effect associate the currently processed tx status
to the first frame in the tx queue with a matching wcid.
This patch fixes several problems related to incorrect tx status
reporting. Furthermore the tx rate selection is much more stable when
communicating with multiple STAs.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit db36f79237
since I'm going to use the data pointer that was removed in
a follow up patch.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Firmware returned VHT cap has the same format that cfg80211
expects. There is no need to parse the vht cap from the firmware
and then set it to ieee80211_sta_vht_cap. Just copying is
sufficient.
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
curr_cmd points to the command that is in processing or waiting
for its command response from firmware. If the function shutdown
happens to occur at this time we should cancel the cmd timer and
put the command back to free queue.
Cc: <stable@vger.kernel.org> # 3.8
Tested-by: Marco Cesarano <marco@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During rmmod mwifiex_sdio processing FUNC_SHUTDOWN command is
sent to firmware. Firmware expcets only FUNC_INIT once WLAN
function is shut down.
Any command pending in the command queue should be ignored and
freed.
Cc: <stable@vger.kernel.org> # 3.8
Tested-by: Daniel Drake <dsd@laptop.org>
Tested-by: Marco Cesarano <marco@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
David S. Miller