mmc: block: Update error handling if block data is not available

While handling IOCTL command, if the block is not available then in the
bail-out path it is trying to free the block data which will be executed
against NULL pointer.

So, don't attempt to free the block data and only release the IOCTL
data.

CRs-Fixed: 476581
Change-Id: Icba46c861258d2d84b1fae5a2f5fca52ffe54255
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
mmc: core: Allow changing bus frequency for SD/eMMC cards in runtime

Currently, bus frequency is set during the card initialization and
never changed until a new card is inserted. In some low power use
cases, scaling the clock frequencies while the card is in transfer
state would allow power savings. This change allows bus frequency
to be changed after the card initialization.

Change-Id: Iac064221199f69d162d91f5311becd735c15700a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Add load based clock scaling support

The SD3.0/eMMC4.5/SDIO3.0 cards can support clock rates upto
200MHz (SDR104 or HS200 bus speed modes). For some workloads
like video playback it isn't necessary for these cards to run
at such high speed. Running at lower frequency, say 50MHz, in
such cases can still meet the deadlines for data transfers.
Scaling down the clock frequency dynamically has huge power
savings not only because the bus is running at lower frequency
but also has an advantage of scaling down the system core
voltage, if supported.

Provide an ondemand clock scaling support similar to cpufreq
ondemand governor having two thresholds, up_threshold and
down_threshold to decide whether to increase the frequency or
scale it down respectively. The sampling interval is in the
order of milliseconds and should be chosen by host drivers that
enable MMC_CAP2_CLK_SCALE capability to take advantage of clock
scaling. The sampling interval mainly depends on the the clock
switching delays and hence a host driver decision. If sampling
interval is too low frequent switching of frequencies can lead
to high power consumption and if sampling interval is too high,
the clock scaling logic would take long time to realize that the
underlying hardware (controller and card) is busy and scale up
the clocks.

Change-Id: I22a5054beec41b0b66b3bf030ddfcf284de448b3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Add sysfs entries for dynamic control of clock scaling

Add sysfs attributes to allow dynamic control of clock scaling
parameters. These attributes are used to enable/disable clock
scaling at runtime and change the up_threshold, down_threshold,
and polling_interval values. Complete documentation for these
sysfs entries are provided at "Documentation/mmc/mmc-dev-attrs.txt".

Change-Id: I4753c75c3b3eeea91e93bceba7af2535b793612e
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: claim mmc host while enabling clock scaling from userspace

A race condition can occur while enabling clock scaling and removal
of the card. If the card is removed just after the host->card check
is successful then there could be NULL pointer dereference later.
Claim mmc host before card availability check to avoid this race
condition.

Change-Id: I6339cad5857732ec6b66280940cd6b8b7ed30614
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: run clock scaling only in valid card state

Clock scaling requires the tuning and if the tuning command
is sent to the card in invalid state, tuning procedure will
fail.

With urgent request mechanism implemented, there is a chance
that clock scaling invoked when card is not in a proper state
to receive the tuning command.

This change checks the card state (by sending the status command)
before invoking the clock scaling request.

Change-Id: Icb71a8e74a9afdc70380a5901cd3d28931959e9c
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
mmc: core: Log MMC clock frequency transitions

Use kernel's ftrace support to capture MMC clock frequency
transitions which can be useful for debugging issues related
to power consumption.

Usage:
mount -t debugfs none /sys/kernel/debug
echo 1 > /sys/kernel/debug/tracing/events/mmc/mmc_clk/enable
cat /sys/kernel/debug/tracing/trace_pipe

Change-Id: I25c4ee39dcbe30e7665902a9f723a5a421b55ca3
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
mmc: core: Add support for notifying host driver while scaling clocks

Host drivers can participate in clock scaling by registering
->notify_load host operation, which allows host driver to carry out
platform specific operations for further power savings or increasing
throughput based on whether load is LOW or HIGH respectively. This
can be applicable to non-ultra high speed cards as well so remove
the check for ultra high speed cards to initialize clock scaling.

Change-Id: Icaab9520135e384f5470db68b2f25c5cdce5663a
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
msm: camera: Fix camera crash in msm_open_config

Add proper check before accessing mctl handle to
avoid camera crash.

Change-Id: I1413f086ab7d94fe223a814bb16867d1dcc0a4bf
CRs-Fixed: 481757
Signed-off-by: Suresh Vankadara <svankada@codeaurora.org>
msm: camera: Fix camera crash when ctrl_q is empty

Add proper error condition if the list is empty and
return error value to upper layers instead of BUG_ON.

Change-Id: I89237e7a27d5fb1e1fd5f1a8a2dfd7ea9a1afff5
CRs-Fixed: 481759
Signed-off-by: Suresh Vankadara <svankada@codeaurora.org>
mmc: msm_sdcc: Add support for dynamic bus clock vote

SDCC controller on some targets like 8660, 8960, 8064 and their
variants connects with Daytona Fabric (DFAB). To achieve max.
possible performance the DFAB clock is voted to 64MHz at the
cost of some power consumption. Since we now have dynamic clock
scaling for SD/eMMC clock we can also scale the DFAB clock
accordingly without impact on performance but have some power
savings in low throughput cases.

Change-Id: Ic26541d6845b65803aa813d672ccabdfc4658d9c
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
radio-iris: Configure repeat count for PS string

- When FM Rx tuned to a station, not receiving complete PS string.
  SOC is not waiting for complete PS string. it is sending PS event
  even if it has part of PS string as well.
- Added support for setting repeat count for PS string
  to get refined PS string from receiver.

CRs-Fixed: 474719
Change-Id: I71c0c1c8af9488573c05d816c37982f9ed935a87
Signed-off-by: Venkateshwarlu Domakonda <Venkateshwarlu@codeaurora.org>
msm: camera: Fix mctl release crash issue.

After mctl release initialize pointer to NULL to
avoid crash.

Change-Id: Ia3e0b1b809f85760a92b5248f402df589c6ace04
Signed-off-by: Suresh Vankadara <svankada@codeaurora.org>
signal: always clear sa_restorer on execve

When the new signal handlers are set up, the location of sa_restorer is
not cleared, leaking a parent process's address space location to
children.  This allows for a potential bypass of the parent's ASLR by
examining the sa_restorer value returned when calling sigaction().

Based on what should be considered "secret" about addresses, it only
matters across the exec not the fork (since the VMAs haven't changed
until the exec).  But since exec sets SIG_DFL and keeps sa_restorer,
this is where it should be fixed.

Given the few uses of sa_restorer, a "set" function was not written
since this would be the only use.  Instead, we use
__ARCH_HAS_SA_RESTORER, as already done in other places.

Example of the leak before applying this patch:

  $ cat /proc/$$/maps
  ...
  7fb9f3083000-7fb9f3238000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
  ...
  $ ./leak
  ...
  7f278bc74000-7f278be29000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
  ...
  1 0 (nil) 0x7fb9f30b94a0
  2 4000000 (nil) 0x7f278bcaa4a0
  3 4000000 (nil) 0x7f278bcaa4a0
  4 0 (nil) 0x7fb9f30b94a0
  ...

[akpm@linux-foundation.org: use SA_RESTORER for backportability]
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Emese Revfy <re.emese@gmail.com>
Cc: Emese Revfy <re.emese@gmail.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Julien Tinnes <jln@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Change-Id: I7ae396ee90c2339c86f7b773d15f5571f8fd54c5
Signed-off-by: Akhila Musunuri <makhila@codeaurora.org>
msm_fb: display: fix iommu page fault when iommu buffer freed

There has possibility that pipe commit come very close to next vsync.
This may cause two consecutive pipe_commits happen within same vsync
period which cause iommu page fault when previous iommu buffer is
freed since mdp stil fetching it. Set ION_IOMMU_UNMAP_DELAYED flag
at ion_map_iommu() to add delay un mapping iommu buffer to fix this problem.
Otherwise four buffer mechanism is needed to avoid this problem..
Also ion_unmap_iommu() may take long time to free an ion buffer. Move
mdp4_overlay_iommu_unmap_freelist(mixer) called after stage_commit()
to increase chance to have pipe_commit (up to stage_commit) is completed
within same vsync period
This patch also fix an potential race condition at wait_for_completion
between show_event thread and wait4vsync thread.

Change-Id: I673b0e368bbcd3120bc26569fe7a7bb82931daaa
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
(cherry picked from commit ada63be0fd32e729e4b91aeeea2a5cfe0830148c)
(cherry picked from commit 799796f15e0b78ffe47975db1cf7f3791cb98129)
Merge "msm: camera: Fix camera crash in msm_open_config"
Merge "msm: camera: Fix camera crash when ctrl_q is empty"
Merge "signal: always clear sa_restorer on execve"
Merge "msm_fb: display: fix iommu page fault when iommu buffer freed"
Merge "msm: camera: Fix mctl release crash issue."