USB: dwc3: Add support for ZLP handling for control endpoint

If the control data length is multiple of endpoint zero maximum
packet size, DWC3 gadger driver is not sending zero length packet
to inform Host of end of data transfer. Due to this, USB enumeration
will fail. Hence add support for handling ZLP in case of control
data length that is mulitple endpoint maximum packet size.

CRs-Fixed: 465540
Change-Id: I139e4798be46c5a3e1e6a6d10fa3cd425301a1eb
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
cfg80211: Extend support for IEEE 802.11r Fast BSS Transition

Add NL80211_CMD_UPDATE_FT_IES to support update of FT IEs to the
WLAN driver and NL80211_CMD_FT_EVENT to send FT events from the
WLAN driver. This will carry the target AP's MAC address along
cfg80211: Extend support for IEEE 802.11r Fast BSS Transition

Add NL80211_CMD_UPDATE_FT_IES to support update of FT IEs to the
WLAN driver and NL80211_CMD_FT_EVENT to send FT events from the
WLAN driver. This will carry the target AP's MAC address along
with the relevant Information Elements. This event is used to
report received FT IEs (MDIE, FTIE, RSN IE, TIE, RICIE). These
changes allow FT to be supported with drivers that use an internal
SME instead of user space option (like FT implementation in
wpa_supplicant with mac80211-based drivers).

Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-commit: 355199e02b831fd4f652c34d6c7673d973da1369
Git-repo: http://git.kernel.org/cgit/linux/kernel/git/linville/
wireless-testing.git/
Change-Id: I03e750494a2735a393f1ec57f3d66e3575265c8a
CRs-fixed: 434525
[deepthi@codeaurora.org: backport to 3.4-This commit includes the
changes from following commits to compile for msm-3.4.
5314526b1743e8e8614293db7d86e480b4fe9824 : cfg80211: add channel
switch notify event
98104fdeda63d57631c9f89e90a7b83b58fcee40 : cfg80211: add P2P
Device abstraction
f4e583c8935c6f52f9385ee7cfbea8f65c66a737 : nl/cfg80211: add the
NL80211_CMD_SET_MCAST_RATE command
ed44a951c72ab409f932b1c15914488308e86da2 : cfg80211/nl80211: Notify
connection request failure in AP mode
77765eaf5cfb6b8dd98ec8b54b411d74ff6095f1 : cfg80211/nl80211: add
API for MAC address ACLs.
04f39047af2a6df64b763ea5a271db24879d0391 : nl80211/cfg80211: add
radar detection command/event.
3713b4e364effef4b170c97d54528b1cdb16aa6b : nl80211: allow splitting
wiphy information in dumps.
ee2aca343c9aa64d277a75a5df043299dc84cfd9 : cfg80211: add ability
to override VHT capabilities.
355199e02b831fd4f652c34d6c7673d973da1369 : cfg80211: Extend
support for IEEE 802.11r Fast BSS Transition.]
Signed-off-by: Deepthi Gowri <deepthi@codeaurora.org>
switch: Reset device's drvdata before destroying it

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: Id6cc72e1c635d6c4e69db3404bf57ebbab35d464
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
jbd2: fix assertion failure in jbd2_journal_flush()

The following race is possible between start_this_handle() and someone
calling jbd2_journal_flush().

Process A                              Process B
start_this_handle().
  if (journal->j_barrier_count) # false
  if (!journal->j_running_transaction) { #true
    read_unlock(&journal->j_state_lock);
                                       jbd2_journal_lock_updates()
                                       jbd2_journal_flush()
                                         write_lock(&journal->j_state_lock);
                                         if (journal->j_running_transaction) {
                                           # false
                                         ... wait for committing trans ...
                                         write_unlock(&journal->j_state_lock);
    ...
    write_lock(&journal->j_state_lock);
    if (!journal->j_running_transaction) { # true
      jbd2_get_transaction(journal, new_transaction);
    write_unlock(&journal->j_state_lock);
    goto repeat; # eventually blocks on j_barrier_count > 0
                                         ...
                                         J_ASSERT(!journal->j_running_transaction);
                                           # fails

We fix the race by rechecking j_barrier_count after reacquiring j_state_lock
in exclusive mode.

Reported-by: yjwsignal@empal.com
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org

CRs-Fixed: 468318
Change-Id: Ibe417ee5c50e257b7521b5ce8bbfa4e13547d4c5
Git-commit: d7961c7fa4d2e3c3f12be67e21ba8799b5a7238a
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Taniya Das <tdas@codeaurora.org>
ARM: Allow arm_memblock_steal() to remove memory from any RAM region

Allow arm_memblock_steal() to remove memory from any RAM region,
including highmem areas.  This allows memory to be stolen from the
very top of declared memory, including highmem areas, rather than
our precious lowmem.

Change-Id: Ib4dbc4e7bc34d402134d96db5ed8118eaffa0245
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Git-commit: 7ac68a4c1de6aac5b0bb231fe6d8505ebe5686d9
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
mm: Retry original migrate type if CMA failed

Currently, __rmqueue_cma will disregard the original migrate type
and only try MIGRATE_CMA for allocations. If the MIGRATE_CMA
allocation fails, the fallback types of the original migrate type
are used. Note that in this current path we never try to actually
allocate from the original migrate type. If the only pages left
in the system are the original migrate type, we will fail the
allocation since we never actually try the original migrate type.
This may lead to infinite looping since the system still (correctly)
calculates there are pages available for allocation and will keep
trying to allocate pages. Fix this degenerate case by allocating
from the original migrate type if the MIGRATE_CMA allocation fails.

Change-Id: I62ab293dc694955eaf88e790131a8565395ba8cb
CRs-Fixed: 470615
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
hrtimer: Consider preemption when migrating hrtimer cpu_bases

When switching to a new cpu_base in switch_hrtimer_base(), we
briefly enable preemption by unlocking the cpu_base lock in two
places. During this interval it's possible for the running thread
to be swapped to a different CPU.

Consider the following example:

CPU #0                                 CPU #1
----                                   ----
hrtimer_start()                        ...
 lock_hrtimer_base()
 switch_hrtimer_base()
  this_cpu = 0;
  target_cpu_base = 0;
  raw_spin_unlock(&cpu_base->lock)
<migrate to CPU 1>
...                                    this_cpu == 0
                                       cpu == this_cpu
                                       timer->base = CPU #0
                                       timer->base != LOCAL_CPU

Since the cached this_cpu is no longer accurate, we'll skip the
hrtimer_check_target() check. Once we eventually go to program
the hardware, we'll decide not to do so since it knows the real
CPU that we're running on is not the same as the chosen base. As
a consequence, we may end up missing the hrtimer's deadline.

Fix this by updating the local CPU number each time we retake a
cpu_base lock in switch_hrtimer_base().

Another possibility is to disable preemption across the whole of
switch_hrtimer_base.  This looks suboptimal since preemption
would be disabled while waiting for lock(s).

Change-Id: I3f76d528ab2288ef5f950f4d048e7f3fa6cf1228
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
hrtimer: Prevent enqueue of hrtimer on dead CPU

When switching the hrtimer cpu_base, we briefly allow for
preemption to become enabled by unlocking the cpu_base lock.
During this time, the CPU corresponding to the new cpu_base
that was selected may in fact go offline. In this scenario, the
hrtimer is enqueued to a CPU that's not online, and therefore
it never fires.

As an example, consider this example:

CPU #0                          CPU #1
----                            ----
...                             hrtimer_start()
                                 lock_hrtimer_base()
                                 switch_hrtimer_base()
                                  cpu = hrtimer_get_target() -> 1
                                  spin_unlock(&cpu_base->lock)
                                <migrate thread to CPU #0>
                                <offline>
spin_lock(&new_base->lock)
this_cpu = 0
cpu != this_cpu
enqueue_hrtimer(cpu_base #1)

To prevent this scenario, verify that the CPU corresponding to
the new cpu_base is indeed online before selecting it in
hrtimer_switch_base(). If it's not online, fallback to using the
base of the current CPU.

Change-Id: I6359cb299ba7e08abf25d3360fcdd925b4c03b69
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
mm: change initial readahead window size calculation

Change the logic which determines the initial readahead window size
such that for small requests (one page) the initial window size
will be x4 the size of the original request, regardless of the
VM_MAX_READAHEAD value. This prevents a rapid ramp-up
that could be caused due to increasing VM_MAX_READAHEAD.

Change-Id: I93d59c515d7e6c6d62348790980ff7bd4f434997
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using dmapools will sooner or
later  trigger the following error:
"ERROR: 256 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!".
Increasing the coherent pool size usually doesn't help much and only
delays such error, because all GFP_ATOMIC DMA allocations are always
served from the special, very limited memory pool.

This patch changes the dmapool code to correctly use gfp flags provided
by the dmapool caller.

Change-Id: Ica4900b55de01a6ab0b858a33d60c7b1542367dc
CRs-Fixed: 473827
Reported-by: Soeren Moch <smoch@web.de>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Soeren Moch <smoch@web.de>
Cc: stable@vger.kernel.org
Git-commit: 387870f2d6d679746020fa8e25ef786ff338dc98
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
block: row: Prevent starvation of regular priority by high priority

At the moment all REGULAR and LOW priority requests are starved as long as
there are HIGH priority requests to dispatch.
This patch prevents the above starvation by setting a starvation limit the
REGULAR\LOW priority requests can tolerate.

Change-Id: Ibe24207982c2c55d75c0b0230f67e013d1106017
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
block: row: Update sysfs functions

All ROW (time related) configurable parameters are stored in ms so there
is no need to convert from/to ms when reading/updating them via sysfs.

Change-Id: Ib6a1de54140b5d25696743da944c076dd6fc02ae
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
usb: dwc3: gadget: fix 'endpoint always busy' bug

If a USB transfer has already been started, meaning
we have already issued StartTransfer command to that
particular endpoint, DWC3_EP_BUSY flag has also
already been set.

When we try to cancel this transfer which is already
in controller's cache, we will not receive XferComplete
event and we must clear DWC3_EP_BUSY in order to allow
subsequent requests to be properly started.

The best place to clear that flag is right after issuing
DWC3_DEPCMD_ENDTRANSFER.

Change-Id: I09824500eedad323ce674ebb4cc170866291be68
CRs-Fixed: 472145
CRs-Fixed: 472815
Cc: stable@vger.kernel.org # v3.4 v3.5 v3.6
Reported-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Git-commit: 041d81f493d90c940ec41f0ec98bc7c4f2fba431
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
lib: genalloc: Use 64 bit types for holding allocations

genalloc may be used to allocate physical addresses in addition
to virtual addresses. On LPAE based systems, physical addresses
are 64-bit which does not fit in an unsigned long. Change the
type used for allocation internally to be 64 bit to ensure that
genalloc can properly allocate physical addresses > 4GB.

Ideally this will just be a temporary workaround until either
a proper fix comes elsewhere or an alternative API is used to
manage physical memory.

Change-Id: Ib10b887730e0c6916de5d1e6f77e771c6cde14bb
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
mmc: sdhci: Enhance ADMA error debugging

Print the controller register dumps and also the descriptors
that software programmed to help identify the root cause for
ADMA Error that controller triggers.

Change-Id: I97beeec078fe8e3f5bfeb2ff34a0639db3038d03
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
lib: memory_alloc: Support 64-bit physical addresses

The current memory allocation code does not support physical
addresses above 32-bits, meaning that LPAE is not supported.
Change the types of the code internally to support 64-bit
physical addresses. Full 64-bit virtual addresses may not be
fully supported so this code will still need an update when
that happens.

Change-Id: I0c4a7b76784981ffcd7f4776d51e05f3592bb7b8
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ufs: Add Platform glue driver for ufshcd

This patch adds Platform glue driver for ufshcd.

Change-Id: Ibe13b8042e4df1e95db71b193da9b042492aaef8
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Tested-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Vinayak Holikatti <vinholikatti@gmail.com>
Signed-off-by: Santosh Yaraganavi <santoshsy@gmail.com>
Patch-mainline: linux-scsi@vger.kernel.org @ 02/26/2013, 12:46
[sthumma@codeaurora.org: Fixed trivial merge conflicts]
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
ufs: Correct the expected data transfersize

This patch corrects the expected data transfer size of the
command UPIU. The current implementation of cmd->transfersize
is wrong as it probably equal to sector size. With this
implementation the transfer size is updated correctly

Change-Id: Ie747aa30fb0cfed627780fb00f835421c2e7f39a
Reported-by: KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Tested-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Santosh Yaraganavi <santoshsy@gmail.com>
Signed-off-by: Vinayak Holikatti <vinholikatti@gmail.com>
Patch-mainline: linux-scsi@vger.kernel.org @ 02/26/2013, 12:46
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
block: row: Fix starvation tolerance values

The current starvation tolerance values increase the boot time
since high priority SW requests are delayed by regular priority requests.
In order to overcome this, increase the starvation tolerance values.

Change-Id: I9947fca9927cbd39a1d41d4bd87069df679d3103
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Documentation: Add memory mapped ARM architected timer binding

Add a binding for the arm architected timer hardware's memory
mapped interface. The mmio timer hardware is made up of one base
frame and a collection of up to 8 timer frames, where each of the
8 timer frames can have either one or two views. A frame
typically maps to a privilege level (user/kernel, hypervisor,
secure). The first view has full access to the registers within a
frame, while the second view can be restricted to particular
registers within a frame. Each frame must support a physical
timer. It's optional for a frame to support a virtual timer.

Change-Id: I6de73d47da16ed78b33367045d24e178500d5cdd
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>