dev_set_drvdata() sets the device specific driver data at
dev->p->driver_data. However, dev is destroyed and has it's
context memory freed in device_destroy(). As a result, calling
dev_set_drvdata() causes a fault when accessing dev->p.
Change-Id: I4b1e6d17db52d0e31caf9b52e59979ff9cbb0c12
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
HSIC HW can operate at SVS digital voltage when it is active.
Currently HSIC is voting for 120Mhz SFAB and 64Mhz DFAB clock
frequencies. Clock frequencies are directly proportional to SVS
voltage. If DFAB is running at 64Mhz or SFAB is running at 120Mhz
or higher SVS is not possible even though HSIC votes for it. Hence
do not vote for SFAB clock frequency and only vote for 32Mhz for
DFAB in order to allow SVS to happen. Voting for SVS voltage reduces
current consumption by 3mA in HSDPA network.
Change-Id: Ic76f0c8346e3387b1647f41f77eb06babbd9a422
Signed-off-by: Iliyan Malchev <malchev@google.com>
HSIC generates interrupt at 4ms interval. If idle power collapse
is enabled when HSIC is active, krait keeps on going into idle
power collapse requesting RPM to handle the sleep set requirement.
If HSIC interrupt comes after 4ms interval, krait comes out of idle
power collapse and it again ask RPM to handle this request therefore
keeps RPM busy handling requests due to frequent idle power collapse.
This has a power impact. Hence only allow standalone power collapse
when HSIC is active to avoid RPM involvement in assisting kraits to
power collapse. Vote for idle power collapse when HSIC goes to low
power mode.
Change-Id: I12d877b1489f26fea32b6e2026aaffea6b5858a9
Signed-off-by: Iliyan Malchev <malchev@google.com>
HSIC controller should send SOF with in 3 msec after completing
the resume signal. If processor is in idle sleep state, the timer
interrupt generated by HSIC controller to indicate resume completion
gets delayed. If the interrupt handler is not run with in 3msec
after resume, the resume sequence is repeated. Disallow processor
idle sleep to avoid multiple resume cycles.
CRs-Fixed: 397154
Change-Id: Ie2c6f60b3a36f46f8246e2e0f41a64675df632a5
Signed-off-by: Iliyan Malchev <malchev@google.com>
Kernel should not use the memory of userspace directly. In msm actuator,
there is wrong use case of using the memory of userspace
in msm_actuator_move_focus. It might cause a kernel crash.
use copy_from_user to avoid that issue.
Change-Id: Icb0852a2358e708741f10c64b0ac429db08b536e
Signed-off-by: Iliyan Malchev <malchev@google.com>
The device might fall in abnormal state in slimport with power on.
The slimport couldn't detect the cable correctly at that time.
We make a sure that the slimport is in power off before turning it on
to avoid that issue.
Change-Id: I119f17e3767221582d1d4330fdfa913552b84503
In the past the iface_stat_fmt would only show global bytes/packets
for the skb-based numbers.
For stall detection in userspace, distinguishing tcp vs other protocols
makes it easier.
Now we report
ifname total_skb_rx_bytes total_skb_rx_packets total_skb_tx_bytes
total_skb_tx_packets {rx,tx}_{tcp,udp,ohter}_{bytes,packets}
Bug: 6818637
Signed-off-by: JP Abgrall <jpa@google.com>
qtaguid limits what can be done with /ctrl and /stats based on group
membership.
This changes removes AID_NET_BW_STATS and AID_NET_BW_ACCT, and picks
up the groups from the gid of the matching proc entry files.
Signed-off-by: JP Abgrall <jpa@google.com>
Change-Id: I42e477adde78a12ed5eb58fbc0b277cdaadb6f94
When the driver is removed from the kernel, you should nullify the
anx7808_client to avoid wrong detecting the slimport cable.
Because it is used in slimport_is_connected().
Change-Id: Ia9cc580e0463e30008493e628a1d3ea9cb07377c
Possible to use the wake_lock in the interrupt handler before initializing
the wake lock. So you should initialize the wake_lock before using it.
Change-Id: I73c1de326403e24c5ba3dae9654cf6bc06f8ea93
enable_irq_wake is a wrapper function of irq_set_irq_wake(). So you don't need
to use irq_set_irq_wake().
Change-Id: I68ceeda1468b449ba32de63430e45dad5ebfeb15
There are wrong error handling in probe(). For example, if you failed to
request the irq, you don't need to free the irq at that time. You just need
to free the irq after you requested the irq successfully.
Change-Id: I353e0cf79b71af760ba4d478fb39ab888e633d0a
- refactor the driver
- Add a VGA Dongle into RX_VGA (00 22 b9 73 69 76 61)
- recovery when backuped dongle type != current dongle type
Change-Id: I3e4dbaac6085308b1997b6b871a5a52fd91c6972
In ext4_nonda_switch(), if the file system is getting full we used to
call writeback_inodes_sb_if_idle(). The problem is that we can be
holding i_mutex already, and this causes a potential deadlock when
writeback_inodes_sb_if_idle() when it tries to take s_umount. (See
lockdep output below).
As it turns out we don't need need to hold s_umount; the fact that we
are in the middle of the write(2) system call will keep the superblock
pinned. Unfortunately writeback_inodes_sb() checks to make sure
s_umount is taken, and the VFS uses a different mechanism for making
sure the file system doesn't get unmounted out from under us. The
simplest way of dealing with this is to just simply grab s_umount
using a trylock, and skip kicking the writeback flusher thread in the
very unlikely case that we can't take a read lock on s_umount without
blocking.
Also, we now check the cirteria for kicking the writeback thread
before we decide to whether to fall back to non-delayed writeback, so
if there are any outstanding delayed allocation writes, we try to get
them resolved as soon as possible.
[ INFO: possible circular locking dependency detected ]
3.6.0-rc1-00042-gce894ca #367 Not tainted
-------------------------------------------------------
dd/8298 is trying to acquire lock:
(&type->s_umount_key#18){++++..}, at: [<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46
but task is already holding lock:
(&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3
which lock already depends on the new lock.
2 locks held by dd/8298:
#0: (sb_writers#2){.+.+.+}, at: [<c01ddcc5>] generic_file_aio_write+0x56/0xd3
#1: (&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3
stack backtrace:
Pid: 8298, comm: dd Not tainted 3.6.0-rc1-00042-gce894ca #367
Call Trace:
[<c015b79c>] ? console_unlock+0x345/0x372
[<c06d62a1>] print_circular_bug+0x190/0x19d
[<c019906c>] __lock_acquire+0x86d/0xb6c
[<c01999db>] ? mark_held_locks+0x5c/0x7b
[<c0199724>] lock_acquire+0x66/0xb9
[<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
[<c06db935>] down_read+0x28/0x58
[<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
[<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46
[<c026f3b2>] ext4_nonda_switch+0xe1/0xf4
[<c0271ece>] ext4_da_write_begin+0x27/0x193
[<c01dcdb0>] generic_file_buffered_write+0xc8/0x1bb
[<c01ddc47>] __generic_file_aio_write+0x1dd/0x205
[<c01ddce7>] generic_file_aio_write+0x78/0xd3
[<c026d336>] ext4_file_write+0x480/0x4a6
[<c0198c1d>] ? __lock_acquire+0x41e/0xb6c
[<c0180944>] ? sched_clock_cpu+0x11a/0x13e
[<c01967e9>] ? trace_hardirqs_off+0xb/0xd
[<c018099f>] ? local_clock+0x37/0x4e
[<c0209f2c>] do_sync_write+0x67/0x9d
[<c0209ec5>] ? wait_on_retry_sync_kiocb+0x44/0x44
[<c020a7b9>] vfs_write+0x7b/0xe6
[<c020a9a6>] sys_write+0x3b/0x64
[<c06dd4bd>] syscall_call+0x7/0xb
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
Commit 080399aaaf ("block: don't mark buffers beyond end of disk as
mapped") exposed a bug in __getblk_slow that causes mount to hang as it
loops infinitely waiting for a buffer that lies beyond the end of the
disk to become uptodate.
The problem was initially reported by Torsten Hilbrich here:
https://lkml.org/lkml/2012/6/18/54
and also reported independently here:
http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511
and then Richard W.M. Jones and Marcos Mello noted a few separate
bugzillas also associated with the same issue. This patch has been
confirmed to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=835019
The main problem is here, in __getblk_slow:
for (;;) {
struct buffer_head * bh;
int ret;
bh = __find_get_block(bdev, block, size);
if (bh)
return bh;
ret = grow_buffers(bdev, block, size);
if (ret < 0)
return NULL;
if (ret == 0)
free_more_memory();
}
__find_get_block does not find the block, since it will not be marked as
mapped, and so grow_buffers is called to fill in the buffers for the
associated page. I believe the for (;;) loop is there primarily to
retry in the case of memory pressure keeping grow_buffers from
succeeding. However, we also continue to loop for other cases, like the
block lying beond the end of the disk. So, the fix I came up with is to
only loop when grow_buffers fails due to memory allocation issues
(return value of 0).
The attached patch was tested by myself, Torsten, and Rich, and was
found to resolve the problem in call cases.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Reported-and-Tested-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
Cc: Stable <stable@vger.kernel.org> # 3.0+
[ Jens is on vacation, taking this directly - Linus ]
--
Stable Notes: this patch requires backport to 3.0, 3.2 and 3.3.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit a76d7bd96d ("ARM: 7467/1: mutex: use generic xchg-based
implementation for ARMv6+") removed the barrier-less, ARM-specific
mutex implementation in favour of the generic xchg-based code.
Since then, a bug was uncovered in the xchg code when running on SMP
platforms, due to interactions between the locking paths and the
MUTEX_SPIN_ON_OWNER code. This was fixed in 0bce9c46bf ("mutex: place
lock in contended state after fastpath_lock failure"), however, the
atomic_dec-based mutex algorithm is now marginally more efficient for
ARM (~0.5% improvement in hackbench scores on dual A15).
This patch moves ARMv6+ platforms to the atomic_dec-based mutex code.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM recently moved to asm-generic/mutex-xchg.h for its mutex
implementation after the previous implementation was found to be missing
some crucial memory barriers. However, this has revealed some problems
running hackbench on SMP platforms due to the way in which the
MUTEX_SPIN_ON_OWNER code operates.
The symptoms are that a bunch of hackbench tasks are left waiting on an
unlocked mutex and therefore never get woken up to claim it. This boils
down to the following sequence of events:
Task A Task B Task C Lock value
0 1
1 lock() 0
2 lock() 0
3 spin(A) 0
4 unlock() 1
5 lock() 0
6 cmpxchg(1,0) 0
7 contended() -1
8 lock() 0
9 spin(C) 0
10 unlock() 1
11 cmpxchg(1,0) 0
12 unlock() 1
At this point, the lock is unlocked, but Task B is in an uninterruptible
sleep with nobody to wake it up.
This patch fixes the problem by ensuring we put the lock into the
contended state if we fail to acquire it on the fastpath, ensuring that
any blocked waiters are woken up when the mutex is released.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Mason <chris.mason@fusionio.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <stable@vger.kernel.org>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The open-coded mutex implementation for ARMv6+ cores suffers from a
severe lack of barriers, so in the uncontended case we don't actually
protect any accesses performed during the critical section.
Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec
code but optimised to remove a branch instruction, as the mutex fastpath
was previously inlined. Now that this is executed out-of-line, we can
reuse the atomic access code for the locking (in fact, we use the xchg
code as this produces shorter critical sections).
This patch uses the generic xchg based implementation for mutexes on
ARMv6+, which introduces barriers to the lock/unlock operations and also
has the benefit of removing a fair amount of inline assembly code.
Cc: <stable@vger.kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Reported-by: Shan Kang <kangshan0910@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If lock refcount is negative, lock will be always failed. To fix this
issue, do not set the lock refcount as negative value.
Change-Id: Ic89f393b60a0ff15313e91566a5055f620752452
Synopsys USB3 Controller (DWC3) has a restriction where size
of OUT requests (TRB) queued to the controller must be aligned
with the endpoint's max packet size.
Since, request buffer is already allocated with the size of
ADB_BULK_BUFFER_SIZE, hence, request this much data from the
controller.
Change-Id: Ibba1a627c9e34b92ddcb44ee2260a004a2b78dfc
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
It is possible to use the wakelock before initializing wakelock.
In this case, wakelock error occurs. To avoid this issue, early initialize
the wakelock in init()
Change-Id: I8fb5450005efa6dbcee6c27b5a3fa551a0adb4dc
If you use the parameter 'maxcpus=n', restrict boot time cpus to n.
To initialize the ETM on cpu, the cpus should be online. So if you restrict
boot time cpus, you can not enable the ETM on cpu which is rectriced(not
enabled). Skip the initialization of the ETM.
Change-Id: Idccf537ff4dce0ae5d1b60ecc1631180ad323fb8
When being completely charged in the offmode charging and pulling out TA
from sleep condition, I gave 1 sec. delay until entering sleep condition again,
in order to prevent the phenomenon that a device doesn't turn off.
We need sometime for an userspace application to handle the usb disconnection
events. There is no effect of power consumption.
Change-Id: I0851cc2b47c3780fd68d3e8965fd0d6f5b7e8312
In off-mode charging, hsic host driver never release wake_lock.
Due to this, system cannot enter the suspend during off-mode
charging. This patch disable the hsic host driver and mdm
driver in off-mode charging to reduce power consumption.
Change-Id: I8580af1d5a9d754982b198c9bd47a98e4b69c725
The interrupts added to the ringbuffer on PTFLUSH and TLBUPDATE
were causing a major increase in the number of interrupts from the GPU.
This was leading to increase in power and loss of performance. Add a check
to turn off IOMMU clocks when going to SLEEP.
Change-Id: I41617dd3b7b3f7d9622523f2a1407b912dbd989e
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
Remove ts_notifier_list from the driver since it is not being
used and is causing extra work to be done in the interrupt
handlers for A2XX, A3XX and Z180.
Change-Id: I5512e36f1e807f3a3e62aeac54cfd3075d4cf7a4
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
This reverts commit de86e6482897db0006151ae9154f181e75f5ab2c.
Commit 7c8527ce ("PM: Prevent runtime suspend during system resume")
fixes the general issue of a parent device being prematurely
runtime suspended before a child device is resumed. It does so
by moving the pm_runtime_put_sync() call from the device_resume()
stage to device_complete(), which happens to act on the devices
in reverse (children before parent) order.
Thus when usb_resume() is called by device_resume(), we know its
parent will be runtime PM enabled and its usage counter is still
non-zero. This obviates the need to do an additional
pm_runtime_get_sync() before calling usb_resume_both() as the
device and its interfaces now have the opportunity to increment
the parent's power.child_count if necessary without fear of
having a runtime suspended parent.
CRs-fixed: 396041
Change-Id: I793ddfbb9bd88634f45f0c1e570a5d616248e3a8
Signed-off-by: Jack Pham <jackp@codeaurora.org>
git://codeaurora.org/external/wlan/prima.git
8cfd26d wlan: Release 3.2.1.13
148c518 Update csrRoamInitGlobals() to support static linking
fff59a1 Send EDCA Parameters After Reassoc
c7f1b8f Populate Correct Scan Mode for Roam
c9990e6 Fix driver hang in csrRoamRoamingStateDisassocRspProcessor
d1ef85b Remove call to palStopTimer for preauth
a31968f Insure that LFR BG scanning is not performed for any non-Infra association
96a9106 Only flush non-P2P results from scan cache prior to LFR scan
ac37d9d De-register lookup UP indication during pre-auth
def1bff Improve convergence of LFR roam candidate scan algorithm
3774f3b Dump neighbor state info when scan is not allowed
524cf61 wlan: Release 3.2.1.12
70e619c Conditionally invoke driver restart API
556271d Notify the Kernel suspend to WCNSS
8aef3d0 Update restart driver API to support statically linked WLAN driver
f9f6457 wlan: Release 3.2.1.11i
d5b0e74 Post proper response to SME when reassoc is rejected
e6c5a60 wlan: Release 3.2.1.11i
bd2182f Post proper response to SME when reassoc is rejected
Signed-off-by: Iliyan Malchev <malchev@google.com>
commit 9ab4233dd0 upstream.
Otherwise the code races with munmap (causing a use-after-free
of the vma) or with close (causing a use-after-free of the struct
file).
The bug was introduced by commit 90ed52ebe4 ("[PATCH] holepunch: fix
mmap_sem i_mutex deadlock")
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
- Adjust context
- madvise_remove() calls vmtruncate_range(), not do_fallocate()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the normal case, when the device is turned off, lcd off function doesn't
work. However, we still need to turn off the panel and DSV convertor. This
patch adds an LCD turn-off function and calls it on device shut down.
Change-Id: I5526f0f08567190050527121d7e0890c05607a68
Signed-off-by: Iliyan Malchev <malchev@google.com>
commit 8a5bdaf3 never allow the runtime suspend if prepare is failed.
The complete phase is invoked when calling __device_suspend.
It allows the runtime suspend again. But if prepare is failed,
__device_suspend won't be called and the complete phase won't also
called. Thus this runtime suspend will be blocked forever.
If prepare is failed, you should allow the runtime suspend again.
Change-Id: I57c7c04609299244a042f2524e1c65dbbdd91ae3
mako does not need loadable kernel modules; disabling support for them reduces
the attack surface on the kernel
Signed-off-by: Iliyan Malchev <malchev@google.com>
In the case which is below,
1. acquire slab for cpu partial list
2. free object to it by remote cpu
3. page->freelist = t
then memory leak is occurred.
Change acquire_slab() not to zap freelist when it works for cpu partial list.
I think it is a sufficient solution for fixing a memory leak.
Below is output of 'slabinfo -r kmalloc-256'
when './perf stat -r 30 hackbench 50 process 4000 > /dev/null' is done.
***Vanilla***
Sizes (bytes) Slabs Debug Memory
------------------------------------------------------------------------
Object : 256 Total : 468 Sanity Checks : Off Total: 3833856
SlabObj: 256 Full : 111 Redzoning : Off Used : 2004992
SlabSiz: 8192 Partial: 302 Poisoning : Off Loss : 1828864
Loss : 0 CpuSlab: 55 Tracking : Off Lalig: 0
Align : 8 Objects: 32 Tracing : Off Lpadd: 0
***Patched***
Sizes (bytes) Slabs Debug Memory
------------------------------------------------------------------------
Object : 256 Total : 300 Sanity Checks : Off Total: 2457600
SlabObj: 256 Full : 204 Redzoning : Off Used : 2348800
SlabSiz: 8192 Partial: 33 Poisoning : Off Loss : 108800
Loss : 0 CpuSlab: 63 Tracking : Off Lalig: 0
Align : 8 Objects: 32 Tracing : Off Lpadd: 0
Total and loss number is the impact of this patch.
Cc: <stable@vger.kernel.org>
Acked-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Memory allocated by kstrdup should be freed,
when kmalloc(kmem_size, GFP_KERNEL) is failed.
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
SDR104 (supported by SD3.0 spec compliant SD cards) bus speed mode
requires DLL (Delay Locked Loop for sampling clock generation) HW
block to be tuned if clock rate is >100MHz. To help the sampling clock
tuning SD3.0 specification has added CMD19.
During card initialization, driver uses these tuning commands to search
for optimal sampling point and then programs the DLL HW with this optimal
sampling point.
In addition, our SDCC controller's DLL HW has a mechansim of data
tracking (CDR) which can be enabled during read transaction so the host
will not lose the sampling point as a result of voltage and, especially,
temperature variations. Tuning pattern commands (CMD19) can be sent
automatically by HW (by using AUTO_CMD19 bit) before any RX transaction
for helping the CDR to track after the correct sampling point.
Although sending CMD19 automatically before every read commands is
overhead and reduces read performance by ~1 MB/s. SD spec does
not mandate to send these commands before every read operations.
This change keeps AUTO_CMD19 disabled by default but provides sysfs
attribute to enable or disable AUTO_CMD19 as per need.
Change-Id: I9ef99a8dde9b9733ea99639cdab2b6714ac50d76
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
IBM reported a deadlock in select_parent(). This was found to be caused
by taking rename_lock when already locked when restarting the tree
traversal.
There are two cases when the traversal needs to be restarted:
1) concurrent d_move(); this can only happen when not already locked,
since taking rename_lock protects against concurrent d_move().
2) racing with final d_put() on child just at the moment of ascending
to parent; rename_lock doesn't protect against this rare race, so it
can happen when already locked.
Because of case 2, we need to be able to handle restarting the traversal
when rename_lock is already held. This patch fixes all three callers of
try_to_ascend().
IBM reported that the deadlock is gone with this patch.
[ I rewrote the patch to be smaller and just do the "goto again" if the
lock was already held, but credit goes to Miklos for the real work.
- Linus ]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
git://codeaurora.org/external/wlan/prima.git
b4798fe Merge branch 'jb-mr1-dev' of git.codeaurora.org:/external/wlan/prima into HEAD
f9f6457 wlan: Release 3.2.1.11i
d5b0e74 Post proper response to SME when reassoc is rejected
e6c5a60 wlan: Release 3.2.1.11i
bd2182f Post proper response to SME when reassoc is rejected
Signed-off-by: Iliyan Malchev <malchev@google.com>
Expose the packing control test.
Test the packing control feature under these scenarios:
- Packing expected: entering write packing state,
staying in write packing state.
- Packing not expected: not entering write packing state
when not supposed to.
- Mixed states: test the ability to shift from packing
to no-packing and back, and the opposite.
(cherry picked from commit 202befb5a5a344f88a0b4fd1ed07b9a2c7ce4e3d)
(cherry picked from commit 91e1e32573321986b141f153ffdb5bcc8affe95b)
Change-Id: I06638dc19aa7703d0571d9699b24ce9977b1bcb8
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
(cherry picked from commit 273c29cec62e3f771bc726cf226c66234ceb80cb)
