defconfigs: Set ROW scheduler as default for ariesve, ancora_tmo and apache too
qdsp5v2: Fix a null pointer dereference.

If ACDB data has not been filled and audio is going to be disabled, audpp_cb
accesses invalid memory address.

This scenario seems to happen when no audio is processed, but audio device is
opened and later closed.

Change-Id: I64724c7a6da8aa2c6da723a8c1122a5ae8d6796f
Revert "Staging: android: binder: More offset validation."

This reverts commit 35cbe09b356b5a412e9e8e1895a5a8d60331ff48.
msm: vidc: cache-flush encoder output buffers after alloc

Flush output buffers explcitly during registering. This ensures
any pending CPU writes (i.e meset to 0 after allocation) are
committed right away, or else this may get flushed _after_
hardware has written the bitstream.

Change-Id: I958466011e7d96c7b5e2691403c8386309997429
Signed-off-by: Praveen Chavan <pchavan@codeaurora.org>
Signed-off-by: c_sridur <sridur@codeaurora.org>
seq_file: remove "%n" usage from seq_file users

All seq_printf() users are using "%n" for calculating padding size,
convert them to use seq_setwidth() / seq_pad() pair.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 652586df95e5d76b37d07a11839126dcfede1621
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[rsiddoji@codeaurora.org: Resolve merge conflicts with ipv4/6 ping
 changes in upstream]
CRs-fixed: 665291
Change-Id: Ia0416c9dbe3d80ff35f24f9c93c3543d1200a327
Signed-off-by: Ravi Kumar <rsiddoji@codeaurora.org>
seq_file: introduce seq_setwidth() and seq_pad()

There are several users who want to know bytes written by seq_*() for
alignment purpose.  Currently they are using %n format for knowing it
because seq_*() returns 0 on success.

This patch introduces seq_setwidth() and seq_pad() for allowing them to
align without using %n format.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 839cc2a94cc3665bafe32203c2f095f4dd470a80)
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
CRs-fixed: 665291
Change-Id: I727d9af5ed320d717295c9d0f82c88623fb181c1
Signed-off-by: David Brown <davidb@codeaurora.org>
vsprintf: ignore %n again

This ignores %n in printf again, as was originally documented.
Implementing %n poses a greater security risk than utility, so it should
stay ignored.  To help anyone attempting to use %n, a warning will be
emitted if it is encountered.

Based on an earlier patch by Joe Perches.

Because %n was designed to write to pointers on the stack, it has been
frequently used as an attack vector when bugs are found that leak
user-controlled strings into functions that ultimately process format
strings.  While this class of bug can still be turned into an
information leak, removing %n eliminates the common method of elevating
such a bug into an arbitrary kernel memory writing primitive,
significantly reducing the danger of this class of bug.

For seq_file users that need to know the length of a written string for
padding, please see seq_setwidth() and seq_pad() instead.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 9196436ab2f713b823a2ba2024cb69f40b2f54a5
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
CRs-fixed: 665291
Change-Id: Id191acaf66e3c395df92b0a77331269b525e3cad
Signed-off-by: David Brown <davidb@codeaurora.org>
target/rd: Refactor rd_build_device_space + rd_release_device_space

This patch refactors rd_build_device_space() + rd_release_device_space()
into rd_allocate_sgl_table() + rd_release_device_space() so that they
may be used seperatly for setup + release of protection information
scatterlists.

Also add explicit memset of pages within rd_allocate_sgl_table() based
upon passed 'init_payload' value.

v2 changes:
  - Drop unused sg_table from rd_release_device_space (Wei)

Change-Id: I0d42113c0e2d703fe7567a804003b034fd4fa0b7
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Git-commit:4442dc8a92b8f9ad8ee9e7f8438f4c04c03a22dc
Git-repo:https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
[ggober@codeaurora.org:resolve trivial merge conflicts in target_core_rd.c]
Signed-off-by: Gopal G Goberu <ggober@codeaurora.org>
ancora: Give extra 1 mb into ion_sf heap

* we missed that in https://github.com/arco/samsung-kernel-msm7x30/commit/d5600570f4b88e2aefa8935034b3c11f89257fab
* to avoid lockups/freezes
block: row: Remove warning massage from add_request

Regular priority queues is marked as "starved" if it skipped a dispatch
due to being empty. When a new request is added to a "starved" queue
it will be marked as urgent.
The removed WARN_ON was warning about an impossible case when a regular
priority (read) queue was marked as starved but wasn't empty. This is
a possible case due to the bellow:
If the device driver fetched a read request that is pending for
transmission and an URGENT request arrives, the fetched read will be
reinserted back to the scheduler. Its possible that the queue it will be
reinserted to was marked as "starved" in the meanwhile due to being empty.

CRs-fixed: 517800
Change-Id: Iaae642ea0ed9c817c41745b0e8ae2217cc684f0c
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Revert "Revert "mmc: core: remove the polling for BKOPS completion""

This reverts commit 76c0b135b76680130ca65ef5044317f8004db10d.
mmc: print an error on FLUSH timeout

Up until now the FLUSH timeout error was not printed and there
was no way to know if the FLUSH completed successfully or not.
Printing the FLUSH failure will help to identify if FS corruption
happened due to this timeout.

Change-Id: Ibbb51d030d7130d63974a1b4319ad4a24621c595
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: block: flush request requeue after timeout.

On some eMMC cards cache flush is taking longer than 30 sec timeout
after HPI issued and -EIO reported to the upper layers. This may result
into journaling issues as flush calls are issued by the file system
joulrnaling code.

This change increases flash cache timeout to 90 sec, in case of timeout
occurs, after HPI issued, flash request re-queued to the block layer queue
to execute it later and keep journaling logic valid.

Conflicts:
	drivers/mmc/card/block.c

Change-Id: I1e968c07056062fd9c8e14e5bc3e62b3b4b99c64
Signed-off-by: Panwar Vivek <vpanwa@codeaurora.org>

Conflicts:

	drivers/mmc/card/block.c

Signed-off-by: Maya Erez <merez@codeaurora.org>
mmc: core: increase timeout for disable cache operation

According to eMMC specification, there is no upper bound defined on
a flush request and the duration of flush operation is left to card
vendor's implementation. This means that it may take a very long
time to complete.

When eMMC cache is disabled, the card has to flush all the data in its
cache. So this means that for certain cards, the driver is not waiting
long enough for the flush to complete during cache disable operation,
leading to data on the card being corrupted.

This change increases the timeout for cache disable operation, thus
preventing data corruption.

CRs-Fixed: 562350
Change-Id: If68328ab56b50c7596800f07ef92c0ab16a55ec0
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: David Ng <dave@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
mmc: core: do not reinsert prepeared FUA and FLUSH requests in stop flow

When mmc context has unblocked from waiting current request because of
urgent request notification coming from block layer, there is prepeared
request.  In the case, when the request is REQ_FUA or REQ_FLUSH, the
flow should not reinsert it back to i/o scheduler (since according to
block layer logic flush requests with data should never enter elevator).
Instead this request starts immediately.

Change-Id: Ia78b56c6135dd1a8d75a98fd5b771a5035e5c360
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: queue: do not clean current request when urgent in progress

As a result of following fix: "mmc: core: do not reinsert prepeared
FUA and FLUSH requests in stop flow" REQ_FUA and REQ_FLUSH requests
are not reinserted back into i/o scheduler, but instead started request
execution.

This change will prevent cleaning current request pointer for such
requests.

Change-Id: I25f8706954fb538be62182c87d5fb20354696b7a
CRs-fixed: 600127
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: core: fix block request queue hang during data crc errors

When data CRC errors occur during write transactions, mmc
block layer queries the card for successful writes. If the card
reports bytes requested as bytes successfully written, the mmc
block layer will end the request with blk_end_request(). If there
is a following async request pending for execution, the request
is thrown away while handling CRC errors leading to hang in
request queue. The hang is visible when user issues a sync()
system call.

The sequence of events are as follows -

mmcqd -> fetch a request -> send it to host driver -> fetch another
request -> wait for previous request to complete -> previous request
is in error -> skip sending current request to host driver and
do error handling for previous request in error.

During the last step, after error handling is completed the mmc
block layer does not requeue the current request which is skipped
and hence the request is infinitely stuck in the driver.

Change-Id: I9528fbe3ccb5b723fcd0793f86cca43906c4c29c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: continue to wait, when unblocked by signal

Mmc thread is waiting for one of following events occurs:
- current running request completion (is_done_rcv)
- new request notification arrived (is_new_req)
- urgent request notification arrived (is_urgent)
or the thread received a signal. In this case none of described events
happened.

This change process the case, when mmc thread was unblocked from wait by
signal, for example system shutdown flow.

Change-Id: I0b4f0cefedc839640c162ad3cdb011d13daaee0c
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
msm7x30: Revert SDC channels to upstream
msm7x30: samsung: Remove PMIC_GPIO_SD_DET

 * Our boards doesn't use this