The A-MPDU code checked against a retry limit, but it was using
the wrong variable to do so. This patch fixes this to assure
proper retry mechanism.
This problem had a side-effect causing the mac80211 flush callback
to remain waiting forever as well. That side effect has been fixed
by commit by Stanislaw Gruszka:
commit f96b08a7e6
Date: Tue Jan 17 12:38:50 2012 +0100
brcmsmac: fix tx queue flush infinite loop
Reference:
https://bugzilla.kernel.org/show_bug.cgi?id=42576
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Alwin Beukers <alwin@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When trying to remove a key, we always send key
flags just setting the key type, not including
the multicast flag and the key ID. As a result,
whenever any key was removed, the unicast key 0
would be removed, causing a complete connection
loss after the second rekey (the first doesn't
cause a key removal). Fix the key removal code
to include the key ID and multicast flag, thus
removing the correct key.
Cc: stable@vger.kernel.org
Reported-by: Alexander Schnaidt <alex.schnaidt@googlemail.com>
Tested-by: Alexander Schnaidt <alex.schnaidt@googlemail.com>
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>
The 'rt2x00lib_probe_dev' function tries to
allocate the workqueue. If the allocation
fails, 'rt2x00_lib_remove_dev' is called on
the error path. Because 'rt2x00dev->workqueue'
is NULL in this case, the 'destroy_workqueue'
call will cause a NULL pointer dereference.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Duplicate the data for iniAddac early on, to avoid having to do redundant
memcpy calls later. While we're at it, make AR5416 < v2.2 use the same
codepath. Fixes a reported crash on x86.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Magnus Määttä <magnus.maatta@logica.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rate control algorithms are supposed to stop processing when they
encounter a rate with the index -1. Checking for rate->count not being
zero is not enough.
Allowing a rate with negative index leads to memory corruption in
ath_debug_stat_rc().
One consequence of the bug is discussed at
https://bugzilla.redhat.com/show_bug.cgi?id=768639
Signed-off-by: Pavel Roskin <proski@gnu.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Driver maintains different flags for WEP, WPA, WPA2 security modes.
Appropriate flag is set using security information provided in
connect request. mwifiex_is_network_compatible() routine uses them
to check if driver's setting is compatible with AP. Association is
aborted if the routine fails.
For some corner cases, it is observed that association is failed
even for valid security information based on association history.
This patch fixes the problem by clearing previous security setting
during each association.
We should set WEP key provided in connect request as default tx key.
This missing change is also added here.
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>
Fixes problem where caller would think routine succeeded when it failed
leading to divide by zero panic.
Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some devices (iwl5100) cannot connect to zd1211rw based AP. It appears that
zd1211 firmware messes up duration_id field if it is not set to zero by driver.
Sniffing traffic shows that zd1211 is transmitting frames with duration_id bits
14 and 15 set and other bits appearing random. Setting duration_id at driver to
zero results zd1211 outputting sane duration_id. This means that firmware is
setting correct values itself and expects duration_id to be zero in first
place.
Looking at vendor driver shows that only PSPoll frames have duration_id set by
driver, for other frames duration_id left zero.
Original bug-report and attached patch at:
http://sourceforge.net/mailarchive/message.php?msg_id=28759111
Reported-by: Tomas Vanek <Tomas.Vanek@fbl.cz>
[modified original patch from bug-report, added check for pspoll frame]
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit adb5066 "ath9k_hw: do not apply the 2.4 ghz ack timeout
workaround to cts" reduced the hardware CTS timeout to the normal
values specified by the standard, but it turns out while it doesn't
need the same extra time that it needs for the ACK timeout, it
does need more than the value specified in the standard, but only
for 2.4 GHz.
This patch brings the CTS timeout value in sync with the initialization
values, while still allowing adjustment for bigger distances.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Reported-by: Seth Forshee <seth.forshee@canonical.com>
Reported-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag"
fixed the interpretation of the KeyMiss flag for keycache based lookups,
however WEP encryption uses a static index, so KeyMiss is always asserted
for it, even though frames are decrypted properly.
Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based
lookup was performed.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Reported-by: Laurent Bonnans <bonnans.l@gmail.com>
Reported-by: Jurica Vukadin <u.ra604@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If driver load is failed, sometimes few pointers may remain
uninitialized ex. priv->wdev, priv->netdev, adapter->sleep_cfm
This will cause NULL pointer dereferance while unloading the
driver.
Signed-off-by: Amitkumar Karwar <akarwar@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>
all works need to be initialized before ieee80211_register_hw
to prevent mac80211 call backs such as drv_start, drv_config
getting started. otherwise we would queue/cancel works before
initializing them and it leads to kernel panic.
this issue can be recreated with the following script
in Chrome laptops with AR928X cards, with background scan
running (or) Network manager is running
while true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
done
EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70
---[ end trace 4f86d6139a9900ef ]---
Registered led device: ath9k-phy0
ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000,
irq=16
Kernel panic - not syncing: Fatal exception
Pid: 456, comm: wpa_supplicant Tainted: G D
3.0.13 #1
Call Trace:
[<81379e21>] panic+0x53/0x14a
[<81004a30>] oops_end+0x73/0x81
[<81004b53>] die+0x4c/0x55
[<81002710>] do_trap+0x7c/0x83
[<81002855>] ? do_bounds+0x58/0x58
[<810028cc>] do_invalid_op+0x77/0x81
[<81040a47>] ? __cancel_work_timer+0xb8/0xe1
[<810489ec>] ? sched_clock_cpu+0x81/0x11f
[<8103f809>] ? wait_on_work+0xe2/0xf7
[<8137f807>] error_code+0x67/0x6c
[<810300d8>] ? wait_consider_task+0x4ba/0x84c
[<81040a47>] ? __cancel_work_timer+0xb8/0xe1
[<810380c9>] ? try_to_del_timer_sync+0x5f/0x67
[<81040a91>] cancel_work_sync+0xf/0x11
[<f88d7b7c>] ath_set_channel+0x62/0x25c [ath9k]
[<f88d67d1>] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k]
[<f88d8899>] ath_radio_disable+0x3f1/0x68e [ath9k]
[<f90d0edb>] ieee80211_hw_config+0x111/0x116 [mac80211]
[<f90dd95c>] __ieee80211_recalc_idle+0x919/0xa37 [mac80211]
[<f90dda76>] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211]
[<812dbed8>] __dev_open+0x82/0xab
Cc: <stable@vger.kernel.org>
Cc: Gary Morain <gmorain@google.com>
Cc: Paul Stewart <pstew@google.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently even if association is failed "iw link" shows some
information about connected BSS and "Tx timeout" error is seen in
dmesg log.
This patch fixes below issues in the code to handle assoc failure
case correctly.
1) "status" variable in mwifiex_wait_queue_complete() is not
correctly updated. Hence driver doesn't inform cfg80211 stack
about association failure.
2) During association network queues are stopped but carrier is
not cleared, which gives Tx timeout error in failure case
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>
In my AMPDU rework, I rely on the sequence numbers of frames. But
I didn't check that the frame has a valid tid before updating the
tracking counters. As a result, the Tx queues were stalled. People
who hit this bug saw that we simply didn't let any data out.
This bug was introduced in 3.3.
This patch fixes that and checks that the frame is a QoS frame before
looking at its tid and changing the counters.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch correct the type of variables containing the rssi
values read from the rxwi.
In function rt2800_agc_to_rssi() 3 variables (rssi0, rssi1, rss2)
defined as int was assigned a 16bit signed values as unsigned.
From a test with a hi-gain antenna I verified that the rxwi
contains signed rssi values in the range -13/+81 (inclusive)
with 0 as an error condition. In case of negative values a
condition is triggered and the function return -128dBm while
the signal is at its maximum. This patch correct the cast so
negative values are not treated as very high positive values
(ex. -13 does not become 243).
Signed-off-by: Luigi Tarenga <luigi.tarenga@gmail.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When an interrupt comes in, we read the reason
bits and collect them into "trans_pcie->inta".
This happens with the spinlock held. However,
there's a bug resetting this variable -- that
happens after the spinlock has been released.
This means that it is possible for interrupts
to be missed if the reset happens after some
other interrupt reasons were already added to
the variable.
I found this by code inspection, looking for a
reason that we sometimes see random commands
time out. It seems possible that this causes
such behaviour, but I can't say for sure right
now since it happens extremely infrequently on
my test systems.
Cc: stable@vger.kernel.org [3.2]
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>
This patch workaround live deadlock problem caused by infinite loop
in brcms_c_wait_for_tx_completion(). I do not consider the patch as
the proper fix, which should fix the real reason of tx queue flush
failure, but patch helps with system lockup.
Reference:
https://bugzilla.kernel.org/show_bug.cgi?id=42576
Reported-and-tested-by: Patrick <ragamuffin@datacomm.ch>
Cc: stable@vger.kernel.org # 3.2+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fixing following sparse warning
>drivers/net/wireless/mwl8k.c:2780:15: warning: incorrect type in assignment (different base types)
>drivers/net/wireless/mwl8k.c:2780:15: expected restricted unsigned short [usertype] channel
>drivers/net/wireless/mwl8k.c:2780:15: got unsigned short [unsigned] [usertype] hw_value
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The intent here was to check whether key->cipher was WEP40 or WEP104.
We do a similar check correctly in several other places in this file.
The current condition is always true.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Alexandre Oliva <oliva@lsd.ic.unicamp.br> says:
"It's an issue brought about by GCC 4.7's partial-inlining, that ends up
splitting the udelay function just at the wrong spot, in such a way that
some sanity checks for constants fails, and we end up calling
bad_udelay.
This patch fixes the problem. Feel free to push it upstream if it makes
sense to you."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The brcmsmac driver isn't a PCI driver any more, it's a bcma one. The
PCI device has been resumed by the PCI driver (the generic PCI layer,
really), we should be resuming just our own driver state.
Also add pr_debug() calls to show that we now actually get the
suspend/resume events.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now the low-level driver actually gets informed that it is getting suspended and resumed.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix the following build warning:
drivers/net/wireless/iwlwifi/iwl-scan.c: In function ‘iwlagn_request_scan’:
drivers/net/wireless/iwlwifi/iwl-scan.c:572: warning: ‘cmd_len’ may be used uninitialized in this function
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Documentation states that the KeyMiss flag is only valid if RxFrameOK is
unset, however empirical evidence has shown that this is false.
When KeyMiss is set (and RxFrameOK is 1), the hardware passes a valid frame
which has not been decrypted. The driver then falsely marks the frame
as decrypted, and when using CCMP this corrupts the rx CCMP PN, leading
to connection hangs.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Same devices can generate interrupt without properly setting bit in
INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
will be disabled by interrupts controller driver.
We discovered that clearing INT_MASK_CSR stops such behaviour. We
previously first read that register, and then clear all know interrupt
sources bits and do not touch reserved bits. After this patch, we write
to all register content (I believe writing to reserved bits on that
register will not cause any problems, I tested that on my rt2800pci
device).
This fix very bad performance problem, practically making device
unusable (since worked without interrupts), reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=658451
We previously tried to workaround that issue in commit
4ba7d99978 "rt2800pci: handle spurious
interrupts", but it was reverted in commit
82e5fc2a34
as thing, that will prevent to detect real spurious interrupts.
Reported-and-tested-by: Amir Hedayaty <hedayaty@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is basically just a cleanup. Large positive numbers get counted as
negative but then get implicitly cast to positive again for the checks
that matter.
This does make a small difference in ipw_handle_promiscuous_rx() when we
test "if (unlikely((len + IPW_RX_FRAME_SIZE) > skb_tailroom(rxb->skb)))"
It should return there, but we don't return until a couple lines later
when we test "if (len > IPW_RX_BUF_SIZE - sizeof(struct ipw_rt_hdr)) {".
The difference is that in the second test the sizeof() means that there
is an implied cast to unsigned.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
An Oops has once been observed, when the SDIO card had been ejected during
IO. The PC value shows, that the dev pointer in b43_op_stop() was NULL.
(I moved the NULL check before the lock, based upon a suggestion from
Julian Calaby <julian.calaby@gmail.com>. -- JWL)
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (69 commits)
pptp: Accept packet with seq zero
RDS: Remove some unused iWARP code
net: fsl: fec: handle 10Mbps speed in RMII mode
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c: add missing iounmap
drivers/net/ethernet/tundra/tsi108_eth.c: add missing iounmap
ksz884x: fix mtu for VLAN
net_sched: sfq: add optional RED on top of SFQ
dp83640: Fix NOHZ local_softirq_pending 08 warning
gianfar: Fix invalid TX frames returned on error queue when time stamping
gianfar: Fix missing sock reference when processing TX time stamps
phylib: introduce mdiobus_alloc_size()
net: decrement memcg jump label when limit, not usage, is changed
net: reintroduce missing rcu_assign_pointer() calls
inet_diag: Rename inet_diag_req_compat into inet_diag_req
inet_diag: Rename inet_diag_req into inet_diag_req_v2
bond_alb: don't disable softirq under bond_alb_xmit
mac80211: fix rx->key NULL pointer dereference in promiscuous mode
nl80211: fix old station flags compatibility
mdio-octeon: use an unique MDIO bus name.
mdio-gpio: use an unique MDIO bus name.
...
It appears that you can only read the sprom contents with aligned 16-bit
reads: anything else causes at least some versions of the broadcom
chipset to abort the PCI transaction, returning 0xff.
This apparently doesn't trigger very often, because most setups don't
use an external srom chip, and the OTP sprom loading doesn't have this
issue. But at least the current 11" Macbook Air does trigger it, and
wireless communications were broken as a result.
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The commit "ath9k: Fix invalid noisefloor reading due to channel update"
preserves the current channel noisefloor readings before updating
channel type at the same channel index. It is also updating the curchan
pointer. As survey updation is also referring curchan pointer to fetch
the appropriate index, which might leads to invalid memory access. This
patch partially reverts the change and stores the noise floor history
buffer before updating channel type w/o updating curchan.
Cc: stable@kernel.org
Cc: Gary Morain <gmorain@google.com>
Cc: Paul Stewart <pstew@google.com>
Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the memory allocation 'nvram_ularray = kmalloc(varsize,
GFP_ATOMIC);' fails we'll leak the memory allocated to 'vbuffer' when
we return -ENOMEM from the function.
This patch resolves the leak by kfree()'ing the allocated memory
before the return.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
also remove an unused macro and a function declaration
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When downloading firmware into the device, the driver fails to check the
return when allocating an skb. When the allocation fails, a BUG can be
generated, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=771656.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (53 commits)
Kconfig: acpi: Fix typo in comment.
misc latin1 to utf8 conversions
devres: Fix a typo in devm_kfree comment
btrfs: free-space-cache.c: remove extra semicolon.
fat: Spelling s/obsolate/obsolete/g
SCSI, pmcraid: Fix spelling error in a pmcraid_err() call
tools/power turbostat: update fields in manpage
mac80211: drop spelling fix
types.h: fix comment spelling for 'architectures'
typo fixes: aera -> area, exntension -> extension
devices.txt: Fix typo of 'VMware'.
sis900: Fix enum typo 'sis900_rx_bufer_status'
decompress_bunzip2: remove invalid vi modeline
treewide: Fix comment and string typo 'bufer'
hyper-v: Update MAINTAINERS
treewide: Fix typos in various parts of the kernel, and fix some comments.
clockevents: drop unknown Kconfig symbol GENERIC_CLOCKEVENTS_MIGR
gpio: Kconfig: drop unknown symbol 'CS5535_GPIO'
leds: Kconfig: Fix typo 'D2NET_V2'
sound: Kconfig: drop unknown symbol ARCH_CLPS7500
...
Fix up trivial conflicts in arch/powerpc/platforms/40x/Kconfig (some new
kconfig additions, close to removed commented-out old ones)
* 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (165 commits)
reiserfs: Properly display mount options in /proc/mounts
vfs: prevent remount read-only if pending removes
vfs: count unlinked inodes
vfs: protect remounting superblock read-only
vfs: keep list of mounts for each superblock
vfs: switch ->show_options() to struct dentry *
vfs: switch ->show_path() to struct dentry *
vfs: switch ->show_devname() to struct dentry *
vfs: switch ->show_stats to struct dentry *
switch security_path_chmod() to struct path *
vfs: prefer ->dentry->d_sb to ->mnt->mnt_sb
vfs: trim includes a bit
switch mnt_namespace ->root to struct mount
vfs: take /proc/*/mounts and friends to fs/proc_namespace.c
vfs: opencode mntget() mnt_set_mountpoint()
vfs: spread struct mount - remaining argument of next_mnt()
vfs: move fsnotify junk to struct mount
vfs: move mnt_devname
vfs: move mnt_list to struct mount
vfs: switch pnode.h macros to struct mount *
...
* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (73 commits)
arm: fix up some samsung merge sysdev conversion problems
firmware: Fix an oops on reading fw_priv->fw in sysfs loading file
Drivers:hv: Fix a bug in vmbus_driver_unregister()
driver core: remove __must_check from device_create_file
debugfs: add missing #ifdef HAS_IOMEM
arm: time.h: remove device.h #include
driver-core: remove sysdev.h usage.
clockevents: remove sysdev.h
arm: convert sysdev_class to a regular subsystem
arm: leds: convert sysdev_class to a regular subsystem
kobject: remove kset_find_obj_hinted()
m86k: gpio - convert sysdev_class to a regular subsystem
mips: txx9_sram - convert sysdev_class to a regular subsystem
mips: 7segled - convert sysdev_class to a regular subsystem
sh: dma - convert sysdev_class to a regular subsystem
sh: intc - convert sysdev_class to a regular subsystem
power: suspend - convert sysdev_class to a regular subsystem
power: qe_ic - convert sysdev_class to a regular subsystem
power: cmm - convert sysdev_class to a regular subsystem
s390: time - convert sysdev_class to a regular subsystem
...
Fix up conflicts with 'struct sysdev' removal from various platform
drivers that got changed:
- arch/arm/mach-exynos/cpu.c
- arch/arm/mach-exynos/irq-eint.c
- arch/arm/mach-s3c64xx/common.c
- arch/arm/mach-s3c64xx/cpu.c
- arch/arm/mach-s5p64x0/cpu.c
- arch/arm/mach-s5pv210/common.c
- arch/arm/plat-samsung/include/plat/cpu.h
- arch/powerpc/kernel/sysfs.c
and fix up cpu_is_hotpluggable() as per Greg in include/linux/cpu.h
This resolves the conflict in the arch/arm/mach-s3c64xx/s3c6400.c file,
and it fixes the build error in the arch/x86/kernel/microcode_core.c
file, that the merge did not catch.
The microcode_core.c patch was provided by Stephen Rothwell
<sfr@canb.auug.org.au> who was invaluable in the merge issues involved
with the large sysdev removal process in the driver-core tree.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The ath6kl driver is causing build failures when the ath6kl bits are
not built as modules. A better fix is forthcoming in a future release,
but for now lets revert the problematic code.
This reverts the following commits:
fde57764efd70385a26a59d954dda4
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In case of firmware crash, reload the firmware and reconfigure it
by triggering ieee80211_hw_restart; mac80211 utility function.
V2 Addressed following comments from Lennert:
- Stop the queues during reload
- Removed atomic_t declaration for hw_restart
- Extend the firmware reload support for sta firmware as well
- Other misc changes
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
for EDMA chip AR_Q_TXE (tx enable for each queue) is read only
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to the latest Ralink vendor drivers, this seems to be the real
RF chipset type.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When USB driver requires padding at the end of frame or URB it will report
this need by increasing return value of get_tx_data_len callback. Common
USB code uses that return value as desired URB length.
Ensure that appropriate part of skb's tailroom exists and is zeroed.
Signed-off-by: Jakub Kicinski <kubakici@wp.pl>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
--
drivers/net/wireless/rt2x00/rt2x00usb.c | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
