Gabor Juhos [Mon, 10 Dec 2012 23:06:41 +0000 (00:06 +0100)]
ath9k: check pdata variable before dereferencing it
Due to my recent commit (ath9k: allow to load EEPROM
content via firmware API) smatch complains about that
the 'pdata' variable in 'ath9k_hw_init' can be NULL
and it is dereferenced before checking that. That is
absolutely correct.
Check the 'pdata' variable before using it to avoid
a NULL pointer dereference.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Thomas Pedersen [Mon, 10 Dec 2012 22:48:03 +0000 (14:48 -0800)]
ath5k: RX timestamp is reported at end of frame
This is true for at least AR5213, and shouldn't be different for other
ath5k PHYs. Tested on AR2413 and AR5414.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Tested-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Thomas Pedersen [Mon, 10 Dec 2012 22:48:02 +0000 (14:48 -0800)]
ath9k_htc: RX timestamp is reported at end of frame
Accurate RX timestamp reporting is important for proper IBSS merging,
mesh synchronization, and MCCA scheduling. Namely, knowing where the TSF
is recorded is needed to sync with the beacon timestamp field.
Tested with AR9271.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Thomas Pedersen [Mon, 10 Dec 2012 22:48:01 +0000 (14:48 -0800)]
ath9k: RX timestamp is reported at end of frame
Accurate RX timestamp reporting is important for proper IBSS merging,
mesh synchronization, and MCCA scheduling. Namely, knowing where the TSF
is recorded is needed to sync with the beacon timestamp field.
Tested with AR9280.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This can lead to a panic if the driver isn't ready to
handle them. Since our interrupt line is shared, we can get
an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks
that even when the interrupt is being freed).
If the op_mode has gone away, we musn't call it. To avoid
this the transport disables the interrupts when the hw is
stopped and the op_mode is leaving.
If there is an event that would cause an interrupt the INTA
register is updated regardless of the enablement of the
interrupts: even if the interrupts are disabled, the INTA
will be changed, but the device won't issue an interrupt.
But the ISR can be called at any time, so we ought ignore
the value in the INTA otherwise we can call the op_mode
after it was freed.
I found this bug when the op_mode_start failed, and called
iwl_trans_stop_hw(trans, true). Then I played with the
RFKILL button, and removed the module.
While removing the module, the IRQ is freed, and the ISR is
called (CONFIG_DEBUG_SHIRQ enabled). Panic.
We know that we have issues with the fw in the reclaim path.
This is why iwl_reclaim doesn't complain too loud when it
happens since it is recoverable. Somehow, the caller of
iwl_reclaim however WARNed when it happens. This doesn't
make any sense.
When I digged into the history of that code, I discovered
that this bug occurs only when we receive a BA notification.
So move the W/A in the BA notification handling code where
it was before.
This patch addresses:
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2387
Tim Gardner [Fri, 7 Dec 2012 13:28:34 +0000 (06:28 -0700)]
iwlwifi: iwlagn_request_scan: Fix check for priv->scan_request
The WARN_ON_ONCE() check for scan_request will not correctly detect
a NULL pointer for scan_type == IWL_SCAN_NORMAL. Make it explicit
that the check only applies to normal scans.
Convert WARN_ON_ONCE to WARN_ON since priv->scan_request really _can't_
be NULL for normal scans. If it is then we should emit frequent warnings.
This smatch warning led to scrutiny of iwlagn_request_scan():
drivers/net/wireless/iwlwifi/dvm/scan.c:894 iwlagn_request_scan() error: we previously assumed 'priv->scan_request' could be null (see line 792)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Gabor Juhos [Mon, 10 Dec 2012 14:30:28 +0000 (15:30 +0100)]
ath9k: allow to load EEPROM content via firmware API
The calibration data for devices w/o a separate
EEPROM chip can be specified via the 'eeprom_data'
field of 'ath9k_platform_data'. The 'eeprom_data'
is usually filled from board specific setup
functions. It is easy if the EEPROM data is mapped
to the memory, but it can be complicated if it is
stored elsewhere.
The patch adds support for loading of the EEPROM
data via the firmware API to avoid this limitation.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Gabor Juhos [Mon, 10 Dec 2012 14:30:27 +0000 (15:30 +0100)]
ath9k: use 'struct ath_hw *' as the first argument for 'ath9k_hw_nvram_read'
The 'ath9k_hw_nvram_read' function takes a
'struct ath_common *' as its first argument.
Almost each of its caller has a 'struct ath_hw *'
parameter in their argument list, and that is
dereferenced in order to get the 'struct ath_common'
pointer.
Change the first argument of 'ath9k_hw_nvram_read'
to be a 'struct ath_hw *', and remove the dereference
calls from the callers.
Also change the type of the first argument of the
ar9300_eeprom_read_{byte,word} functions.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Gabor Juhos [Mon, 10 Dec 2012 14:30:25 +0000 (15:30 +0100)]
ath9k: move duplicated debug message to 'ath9k_hw_nvram_read'
The fill_eeprom functions are printing the same
debug message in case the 'ath9k_hw_nvram_read'
function fails. Remove the duplicated code from
fill_eeprom functions and add the ath_dbg call
directly into 'ath9k_hw_nvram_read'.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rafał Miłecki [Mon, 10 Dec 2012 06:53:56 +0000 (07:53 +0100)]
bcma: mips: fix clearing device IRQ
We were using wrong IRQ number so clearing wasn't working at all.
Depending on a platform this could result in a one device having two
interrupts assigned. On BCM4706 this resulted in all IRQs being broken.
Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: stable@vger.kernel.org Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Mon, 10 Dec 2012 01:52:37 +0000 (07:22 +0530)]
ath9k_hw: Add HW cap for PAPRD
Add a HW capability to indicate whether PAPRD is enabled
for the card, since PAPRD could be enabled in the EEPROM, but
disabled in the driver. This makes things clearer.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith Manoharan [Mon, 10 Dec 2012 01:52:32 +0000 (07:22 +0530)]
ath9k_hw: Fix PAPRD training
The PAPRD training control registers have to be
programmed with values that depend on the chip. This patch
ensures that the correct values are chosen for the chip
in use.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Maia Kozheva [Sun, 9 Dec 2012 09:07:40 +0000 (16:07 +0700)]
rt2800usb: Add support for 2001:3c1e (D-Link DWA-125 rev B1) USB Wi-Fi adapter
D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a
Ralink chipset supported by the rt2800usb driver. Currently, to work
around the problem (it's missing in all present kernel versions,
up to and including 3.7.x), I had to add this to /etc/rc.local:
carl9170: fix copy and paste mishap in carl9170_handle_mpdu
This patch fixes a regression which was introduced by:
"carl9170: split up carl9170_handle_mpdu"
Previously, the ieee80211_rx_status was kept on the
stack of carl9170_handle_mpdu. Now it's passed into
the function as a pointer parameter. Hence, the old
memcpy call needs to be fixed.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Fri, 7 Dec 2012 16:04:13 +0000 (17:04 +0100)]
brcmsmac: do a read after the write of the objmem on broken PCIe controllers
As described in the documentation of bcma_wflush16 in drivers/net
/wireless/brcm80211/brcmsmac/types.h some PCIe controllers of Broadcom
SoCs are broken. The PCIe controller on these SoCs are mostly used to
connect some additional wifi device to the SoC and some of these wifi
devices are supported by brcmsmac.
For my BCM43224 connected to the broken PCIe controller of the BCM4718 I
need an extra read after write in brcms_b_write_objmem() to prevent a
Data bus error. This fixes the problem reading tsf_random later.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit "ath9k: Fix the 'xmit' debugfs file" changed the
the array size of ath_stats.txstats to IEEE80211_NUM_ACS,
which is wrong because the HW queue number is used to
update the statistics. Revert back to using ATH9K_NUM_TX_QUEUES.
Reported-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Larry Finger [Fri, 7 Dec 2012 03:55:16 +0000 (21:55 -0600)]
b43legacy: Fix firmware loading when driver is built into the kernel
Recent versions of udev cause synchronous firmware loading from the
probe routine to fail because the request to user space times out.
The original fix for b43legacy (commit a3ea2c7) moved the firmware
load from the probe routine to a work queue, but it still used synchronous
firmware loading. This method is OK when b43legacy is built as a module;
however, it fails when the driver is compiled into the kernel.
This version changes the code to load the initial firmware file
using request_firmware_nowait(). A completion event is used to
hold the work queue until that file is available. The remaining
firmware files are read synchronously.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> (V3.4+) Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Thu, 6 Dec 2012 23:35:53 +0000 (00:35 +0100)]
brcmsmac: add support for cores with revision 17
This adds support for bcma wifi core revision 17 which is found on
BCM4716/4717/4718 SoCs. The firmware version 610.812 for brcmsmac found
in linux-firmware does not support these cores, but a firmware
generated with b43-fwcutter from the proprietary broadcom wireless
driver works with these chips. This wifi core contains a revision 5
N-PHY and a revision 7 radio of type 0x2056.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Turns out reverting commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd
"ath9k_hw: Updated AR9003 tx gain table for 5GHz" was not enough to
bring the tx power back to normal levels on devices like the
Buffalo WZR-HP-G450H, this one needs to be reverted as well.
This revert improves tx power by ~10 db on that device
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Cc: rmanohar@qca.qualcomm.com Signed-off-by: John W. Linville <linville@tuxdriver.com>
The call to brcmf_dbg(ERROR, ...) only resulted in a log message
when compiled with -DDEBUG. Error messages are valuable for resolving
issues so this patch replaces it with brcmf_err(...) so they always
end up in the log.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmsmac: fix uninitialized variable warning on arm architecture
Using gcc v4.7.2 gave following warning:
CC [M] drivers/net/wireless/brcm80211/brcmsmac/aiutils.o
brcmsmac/aiutils.c: In function 'ai_deviceremoved':
brcmsmac/aiutils.c:733:9: error: 'w' may be used uninitialized
in this function [-Werror=uninitialized]
Inspection of the pci_read_config_dword() function showed it can
return without modifying the output variable 'w' so this patch
initializes it to 0.
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Piotr Haber <phaber@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Eytan Lifshitz [Sat, 1 Dec 2012 18:59:49 +0000 (20:59 +0200)]
iwlwifi: Change define and struct names in iwl-eeprom-parse.h
Since we will have several forms of NVM (EEPROM, OTP, etc.)
and they will have different layouts, make the parsed data
more generic. This allows functional code to be independent
of a specific layout.
Also change some variables and function names from having
"eeprom" to "nvm" in their name.
Bill Pemberton [Mon, 3 Dec 2012 14:56:40 +0000 (09:56 -0500)]
rtl8187: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:39 +0000 (09:56 -0500)]
rt2x00: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Gertjan van Wingerde <gwingerde@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: users@rt2x00.serialmonkey.com (moderated for non-subscribers) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:38 +0000 (09:56 -0500)]
p54: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:37 +0000 (09:56 -0500)]
orinoco: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:35 +0000 (09:56 -0500)]
libertas: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Dan Williams <dcbw@redhat.com> Cc: libertas-dev@lists.infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:34 +0000 (09:56 -0500)]
iwlwifi: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Johannes Berg <johannes.berg@intel.com> Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com> Cc: Intel Linux Wireless <ilw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:32 +0000 (09:56 -0500)]
ipw2x00: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:31 +0000 (09:56 -0500)]
brcm80211: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Brett Rudley <brudley@broadcom.com> Cc: Roland Vossen <rvossen@broadcom.com> Cc: Arend van Spriel <arend@broadcom.com> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com> Cc: Kan Yan <kanyan@broadcom.com> Cc: brcm80211-dev-list@broadcom.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:29 +0000 (09:56 -0500)]
atmel: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:28 +0000 (09:56 -0500)]
ath5k: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Nick Kossifidis <mickflemm@gmail.com> Cc: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Cc: linux-wireless@vger.kernel.org Cc: ath5k-devel@lists.ath5k.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:27 +0000 (09:56 -0500)]
wireless: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bill Pemberton [Mon, 3 Dec 2012 14:56:26 +0000 (09:56 -0500)]
rfkill: remove __dev* attributes
CONFIG_HOTPLUG is going away as an option. As result the __dev*
markings will be going away.
Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
and __devexit.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:08 +0000 (18:46 +0100)]
ssb: register watchdog driver
Register the watchdog driver to the system if it is a SoC. Using the
watchdog on a non SoC device, like a PCI card, will make the PCI
card die when the timeout expired, but starting it again is not
supported by ssb.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:07 +0000 (18:46 +0100)]
ssb: extif: add methods for watchdog driver
The watchdog driver wants to set the watchdog timeout in ms and not in
ticks, add a method converting ms to ticks before setting the watchdog
register. Return the ticks or millisecond the timer was set to in case
the provided value was bigger than the max allowed value.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:05 +0000 (18:46 +0100)]
ssb: add methods for watchdog driver
The watchdog driver wants to set the watchdog timeout in ms and not in
ticks, which is depending on the SoC type and the clock.
Calculate the number of ticks per millisecond and provide two functions
for the watchdog driver. Also return the ticks or millisecond the timer
was set to in case the provided value was bigger than the max allowed
value.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:04 +0000 (18:46 +0100)]
ssb: set the PMU watchdog if available
Some ssb based devices have a PMU and the PMU watchdog register should
be used instead of the register in the chip common part, if the device
has a PMU. This patch also calculates the maximal number the watchdog
could be set to.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:02 +0000 (18:46 +0100)]
bcma: register watchdog driver
Register the watchdog driver to the system if this is a SoC. Using the
watchdog on a non SoC device, like a PCIe card, will make the PCIe
card die when the timeout expired, but starting it again is not
supported by bcma.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:01 +0000 (18:46 +0100)]
bcma: add methods for watchdog driver
The watchdog driver wants to set the watchdog timeout in ms and not in
ticks, which is depending on the SoC type and the clock.
Calculate the number of ticks per millisecond and provide two functions
for the watchdog driver. Also return the ticks or millisecond the timer
was set to in case the provided value was bigger than the max allowed
value.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:46:00 +0000 (18:46 +0100)]
bcma: set the pmu watchdog if available
Mostly all bcma based devices have a PMU and the PMU watchdog should be
used and not the old one in chip common. This patch also calculates the
maximal number the watchdog could be set to.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hauke Mehrtens [Wed, 5 Dec 2012 17:45:58 +0000 (18:45 +0100)]
ssb/bcma: add common header for watchdog
This adds a common header for watchdog functions, so a watchdog driver
just needs to use this and could provide watchdog functionality for ssb
and bcma based SoCs. Patches for a watchdog driver using this interface
will be send later.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Cc: stable@vger.kernel.org [3.7+] Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
carl9170: explain why sta cannot be NULL for ampdus
Dan Carpenter reported that smatch detected a potential
problem with the code [1]:
drivers/net/wireless/ath/carl9170/tx.c:1488 carl9170_op_tx()
error: we previously assumed 'sta' could be null (see line 1482)
drivers/net/wireless/ath/carl9170/tx.c
1482 if (sta) {
^^^^^ New check.
[...]
1485 }
1487 if (info->flags & IEEE80211_TX_CTL_AMPDU) {
1488 run = carl9170_tx_ampdu_queue(ar, sta, skb);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Old dereference of "sta" inside the call to carl9170_tx_ampdu_queue().
A range of solutions have been discussed in [2] and
we agreed on the following: "
> we might as well add a comment to carl9170_tx_ampdu_queue
> and explain the situation [in a way that's obvious to a
> human reader]. This way we can save the "if"... which is
> a small win since carl9170_op_tx is sort of a hot-path.
Putting a comment there is fine. Without the comment
it's easy for a human reader to get confused why the
check is there. So long as humans can read the code,
that's all that matters."
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
LD drivers/net/wireless/brcm80211/built-in.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/fwil.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/fwil.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/fweh.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/fweh.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_common.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/usb.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/usb.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.o
LD [M] drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.o
LD drivers/net/wireless/brcm80211/brcmsmac/built-in.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1311:6: warning: context imbalance in 'brcms_down' - unexpected unlock
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1598:6: warning: context imbalance in 'brcms_rfkill_set_hw_state' - unexpected unlock
CC [M] drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/ampdu.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/antsel.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/antsel.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/channel.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/channel.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/main.c
drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:36: warning: Initializer entry defined twice
drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:43: also defined here
CC [M] drivers/net/wireless/brcm80211/brcmsmac/main.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy_shim.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/pmu.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/pmu.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/rate.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/rate.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/stf.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/stf.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/aiutils.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/aiutils.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c:3313:46: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:17688:47: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:18187:53: warning: cast truncates bits from constant value (ffff3fff becomes 3fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:21160:36: warning: cast truncates bits from constant value (ffff3fff becomes 3fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:23321:35: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:28343:44: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/dma.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/dma.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.o
CHECK drivers/net/wireless/brcm80211/brcmsmac/debug.c
CC [M] drivers/net/wireless/brcm80211/brcmsmac/debug.o
LD [M] drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.o
LD drivers/net/wireless/brcm80211/brcmutil/built-in.o
CHECK drivers/net/wireless/brcm80211/brcmutil/utils.c
CC [M] drivers/net/wireless/brcm80211/brcmutil/utils.o
LD [M] drivers/net/wireless/brcm80211/brcmutil/brcmutil.o
Building modules, stage 2.
MODPOST 3 modules
CC drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.mod.o
LD [M] drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko
CC drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.mod.o
LD [M] drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko
CC drivers/net/wireless/brcm80211/brcmutil/brcmutil.mod.o
LD [M] drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko
Cc: Brett Rudley <brudley@broadcom.com> Cc: Roland Vossen <rvossen@broadcom.com> Cc: Arend van Spriel <arend@broadcom.com> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com> Cc: Kan Yan <kanyan@broadcom.com> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list@broadcom.com Reported-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge tag 'nfc-fixes-3.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0
This is an NFC LLCP fix for 3.7 and contains only one patch.
It fixes a potential crash when receiving an LLCP HDLC frame acking a frame
that is not the last sent one. In that case we may dereference an already
freed pointer.
Johannes Berg [Wed, 5 Dec 2012 08:49:14 +0000 (09:49 +0100)]
mac80211: cancel work instead of waiting for it to do nothing
If the sdata work is pending while the interface is stopped,
we currently flush it. If it's not running this means waiting
for it to run, which could take a while if the workqueue is
backlogged. However, the work exits right away if it starts
to run while the interface is already stopping. There's no
point in waiting for that, so use cancel_work_sync() instead.
Reported-by: Ben Greear <greearb@candelatech.com> Tested-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Marco Porsch [Wed, 5 Dec 2012 23:04:26 +0000 (15:04 -0800)]
mac80211: don't drop mesh peering frames from unknown STA
Previously, mesh peering frames from a STA without a station
entry were being dropped.
Mesh Peering Open and other frames (WLAN_CATEGORY_SELF_PROTECTED)
are valid mesh peering frames even if received from a yet unknown
station; the STA entry will be created in mesh_peer_init later.
The problem didn't occur previously since both STAs receive each
other's beacons which created the STA entry. However, this causes
an unnecessary delay and beacons might not be received if either
node is in PS mode.
Signed-off-by: Marco Porsch <marco.porsch@etit.tu-chemnitz.de>
[reword commit log a bit] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Helmut Schaa [Wed, 5 Dec 2012 13:36:12 +0000 (14:36 +0100)]
mac80211: skip radiotap space calculation if no monitor exists
The radiotap header length "needed_headroom" is only required if we're
sending the skb to a monitor interface. Hence, move the calculation a
bit later so the calculation can be skipped if no monitor interface is
present.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
To fix problem workaround by above commit use
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL flag (see change log for
"mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL" patch).
Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=42828 Bisected-by: Francisco Pina Martins <f.pinamartins@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending
failed BAR frames later instead of tearing down aggr" caused regression
on rt2x00 hardware (connection hangs). This regression was fixed by
commit be03d4a45c09ee5100d3aaaedd087f19bc20d01 "rt2x00: Don't let
mac80211 send a BAR when an AMPDU subframe fails". But the latter
commit caused yet another problem reported in
https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22
After long discussion in this thread:
http://mid.gmane.org/20121018075615.GA18212@redhat.com
and testing various alternative solutions, which failed on one or other
setup, we have no other good fix for the issues like just revert both
mentioned earlier commits.
To do not affect other hardware which benefit from commit f0425beda4d404a6e751439b562100b902ba9c98, instead of reverting it,
introduce flag that when used will restore mac80211 behaviour before
the commit.
Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
[replaced link with mid.gmane.org that has message-id] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Saravana [Tue, 4 Dec 2012 14:17:42 +0000 (19:47 +0530)]
mac80211: add debug file for mic failure
The mic failure count provides the number of mic failures that
have happened on a given key (without a countermeasure being
started, since that would remove the key).
Johannes Berg [Tue, 4 Dec 2012 19:49:42 +0000 (20:49 +0100)]
cfg80211: check no-OFDM flag for channels wider than 20 MHz
For channels wider than 20 MHz OFDM will be used, so when
checking whether or not a channel is usable, check for the
no-OFDM flag if the channel is wider than 20 MHz.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>