Squashed update of kernel from 3.4.77 to 3.4.78
block: bfq: Squashed update from v6r2 to v7
cpufreq: Fix policy getting stuck when user & kernel min/max don't overlap

Every __cpufreq_set_policy starts with checking the new policy min/max has
some overlap with the current policy min/max. This works out fine until we
end up with the policy min/max being set to a range that doesn't overlap
with the user policy min/max. Once we get into this situation, the check at
the start of __cpufreq_set_policy fails and prevents us from getting out of
this state.

This only happens when one of the CPUFREQ_ADJUST/CPUFREQ_INCOMPATIBLE
notifiers called inside __cpufreq_set_policy pick a min/max outside the
range of user policy min/max.

The real intent of the check at the start of __cpufreq_set_policy is to
make sure userspace can't set user policy min > user policy max. Since
__cpufreq_set_policy always gets called only with current user policy
min/max except when the actual user space policy min/max is changed, we can
fix the issue by simply checking the new policy min/max against current
user policy min/max.

Change-Id: Iaac805825e64d7985c41fb9052bd96baacdf3d6f
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
arm: if there's no handler we need to restore sigmask, syscall or no syscall

CRs-fixed: 592079
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Git-commit: 7dfae72027cd8345247e675a3b27439df95fe06e
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-stable.git
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
arm: new way of handling ERESTART_RESTARTBLOCK

new "syscall start" flag; handled in syscall_trace() by switching
syscall number to that of syscall_restart(2).  Restarts of that
kind (ERESTART_RESTARTBLOCK) are handled by setting that bit;
syscall number is not modified until the actual call.

CRs-fixed: 592079
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Git-commit: 6b5c8045ecc7e726cdaa2a9d9c8e5008050e1252
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-stable.git
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
driver core: fix possible missing of device probe

Inside bus_add_driver(), one device might be added(device_add()) into
the bus or probed which is triggered by deferred probe
just after completing of driver_attach() and before
'klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers)',
so the device won't be probed by this driver.

This patch moves the below line

	'klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers)'

before driver_attach() inside bus_add_driver() to fix the
problem.

CRs-Fixed: 588802
Change-Id: I9250b399d57a89870d1df220b97fdca275e2e1a9
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 190888ac01d059e38ffe77a2291d44cafa9016fb
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
block: do not notify urgent request, when flush with data in flight

MMC device driver implements URGENT request execution with priority
(using stop flow), as a result currently running (and prepeared) request
may be reinserted back into I/O scheduler. This will break block layer
logic of flushes (flush request should not be inserted into I/O scheduler).

Block layer flush machinery keep q->flush_data_in_flight list updated with
started but not completed flush requests with data (REQ_FUA).

This change will not notify underling block device driver about pending
urgent request during flushes in flight.

Change-Id: I98113621223fe0c7d224de023db888a73bd62b48
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Bluetooth: Replace sprintf with snprintf

Change will replace sprintf with snprintf, since sprintf is a
banned function.

CRs-FIxed: 548220
Change-Id: I32f5ab1f3707e5bbe43c31a7ad4611b67557b267
Signed-off-by: Juffin Alex Varghese <jalex@codeaurora.org>
block: bfq: Squashed update from v7 to v7r1
block: add a flag to identify PM request

Add a flag REQ_PM to identify the request is PM related, such requests
will not change the device request queue's runtime status. It is
intended to be used in driver's runtime PM callback, so that driver can
perform some IO to the device there with the queue's runtime status
unaffected. e.g. in SCSI disk's runtime suspend callback, the disk will
be put into stopped power state, and this require sending a command to
the device. Such command processing should not change the disk's runtime
status.

Change-Id: I522bbee6cc911cefeefba50517ebc283e2838918
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Git-commit: 66311274691ec65972cad3626057fa8d00c146d8
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[sthumma@codeaurora.org: resolve trival merge conflicts]
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
block: add runtime pm helpers

Add runtime pm helper functions:

void blk_pm_runtime_init(struct request_queue *q, struct device *dev)
  - Initialization function for drivers to call.

int blk_pre_runtime_suspend(struct request_queue *q)
  - If any requests are in the queue, mark last busy and return -EBUSY.
    Otherwise set q->rpm_status to RPM_SUSPENDING and return 0.

void blk_post_runtime_suspend(struct request_queue *q, int err)
  - If the suspend succeeded then set q->rpm_status to RPM_SUSPENDED.
    Otherwise set it to RPM_ACTIVE and mark last busy.

void blk_pre_runtime_resume(struct request_queue *q)
  - Set q->rpm_status to RPM_RESUMING.

void blk_post_runtime_resume(struct request_queue *q, int err)
  - If the resume succeeded then set q->rpm_status to RPM_ACTIVE
    and call __blk_run_queue, then mark last busy and autosuspend.
    Otherwise set q->rpm_status to RPM_SUSPENDED.

The idea and API is designed by Alan Stern and described here:
http://marc.info/?l=linux-scsi&m=133727953625963&w=2

Change-Id: I486612af79c7887116f70a4fde552c107f7fa360
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Git-commit: 6c9546675864f51506af69eca388e5d922942c56
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
block: implement runtime pm strategy

When a request is added:
    If device is suspended or is suspending and the request is not a
    PM request, resume the device.

When the last request finishes:
    Call pm_runtime_mark_last_busy().

When pick a request:
    If device is resuming/suspending, then only PM request is allowed
    to go.

The idea and API is designed by Alan Stern and described here:
http://marc.info/?l=linux-scsi&m=133727953625963&w=2

Change-Id: If9c8332164afba6aeca984277e3398008ad9c45a
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Git-commit: c8158819d506a8aedeca53c52dfb709a0aabe011
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
blkpm: avoid sleep when holding queue lock

In blk_post_runtime_resume, an autosuspend request will be initiated for
the device. Since we are holding the queue lock, we can't sleep and thus
we should use the async version to initiate an autosuspend, i.e.
pm_request_suspend instead of pm_runtime_suspend, which might sleep.

Change-Id: I28cbe7e20ffdcb8f7b3329bf3b827c942dd1b45a
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Git-commit: c60855cdb976c632b3bf8922eeab8a0e78edfc04
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
block: allow REQ_PM requests even when the device is suspended

Some times even though the block device is suspended by the block layer
the low-level driver might want to queue the PM requests to the device.
Allow such requests to get peeked as the blk_pm_add_request() has already
added it to the I/O scheduler otherwise the request would be forever stuck
in the I/O scheduler without being fetched by the driver.

Change-Id: I353943a7008ea1d92ff825d220cad1828fe37c27
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Squashed update of kernel from 3.4.78 to 3.4.79
Squashed update of kernel from 3.4.79 to 3.4.80

Change-Id: I5c3ed48a5eb0fa3ca9f692e5ee536801fa739451
Squashed update of kernel from 3.4.80 to 3.4.81

Change-Id: Iff8c4f7db5351ea7484bacbc2fbd1a89c9ab3650
gcc-wrapper: ignore slub.c warning

Change-Id: I44a1ed9a2762edc7ccca4bf453920f00f6f28ae5
Squashed update of kernel from 3.4.81 to 3.4.82

Change-Id: Ib841c2248bf6ee1770463cee15290c53ffe84d99
fix false disconnect due to a signal sent to the reading process

- In the current implementation, when a signal is sent to the reading process,
  read is cancelled by calling usb_ep_dequeue, which lead into calling
  acc_complete_out with ECONNRESET, but the current logic treats it as
  disconnection, which makes the device inaccessible until cable is actually
  disconnected.
- The fix calls disconnect only when ESHUTDOWN error is passed.
- If data has already arrived while trying cancelling, the data is marked
  as available, and it will be read out on the next read. This is necessary
  as USB bulk is assumed to guarantee no data loss.

Change-Id: I8c6c5237eed051e722eb3027c72a5ef3bf5ed33f
Signed-off-by: keunyoung <keunyoung@google.com>