scripts/kallsyms: filter symbols not in kernel address space

This patch uses CONFIG_PAGE_OFFSET to filter symbols which
are not in kernel address space because these symbols are
generally for generating code purpose and can't be run at
kernel mode, so we needn't keep them in /proc/kallsyms.

For example, on ARM there are some symbols which may be
linked in relocatable code section, then perf can't parse
symbols any more from /proc/kallsyms, this patch fixes the
problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)

Change-Id: I3d6321b7d87727c7c2802b3924f2e89a28e4b9ca
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@vger.kernel.org
Git-commit: f6537f2f0eba4eba3354e48dbe3047db6d8b6254
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
CRs-fixed: 583755
[nleeder@codeaurora.org: move flag to Makefile because original file
 scripts/link-vmlinux.sh does not exist in 3.4]
Signed-off-by: Neil Leeder <nleeder@codeaurora.org>
Signed-off-by: Mekala Natarajan <mekalan@codeaurora.org>
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>
msm: mdp: Disable early suspend only for the MDP driver

Early suspend is deprecated in the framework but disabling it
completely can affect other subsystems. Disabling only for the
MDP driver.

Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
msm: mdp: Disable early suspend locally

undefing at the header level could mess with other components.

Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
msm: display: command mode panel release fence

For command mode panel, release fence should be signaled after the buffer is
sent to the panel.  For performance consideration, allow one more commit to be
queued.  Keep the second kick off as short as enough.

Change-Id: I19af075ebf480d3e81b46b1cd2ef21a2893f143e
Signed-off-by: Ken Zhang <kenz@codeaurora.org>
Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
Signed-off-by: Iliyan Malchev <malchev@google.com>
msm: mdp: Change msmfb kworker to kthread

This worker can be a longer running task depending on the number
of frames queued, hence change it to a thread.

Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
Change-Id: Iebf7e95d0486ac43aa6a12d70442936600c0249a
msm: mdp: Update sync pt. behaviour

Add a retire fence and clean up the existing release fence
implementation

Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
Change-Id: Iecf7e95d0786ac43aa6a12d70442936600c0249a
msm: display: Set dsi_panel_off flag in panel off function

* Because command mode panels are capable of queuing multiple commits
  while panel is turning off, the dsi_panel_off flag must be
  manipulated in the actual panel off function (panel_disable) to avoid
  a race where the commit thread re-enables a panel that has already
  been turned off.

Change-Id: I1e678013fbf7b147464eeaed76a31e82129f8868
Revert "ghost: Disable module whitelisting"

We don't have any problems. Enable for security.
This reverts commit af6707f4047d558dc6be979489b6afbd9d356ebd.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
[SCSI] Remove scsi_wait_scan module

scsi_wait_scan was introduced with asynchronous host scanning as a hack
for distributions that weren't using proper udev based wait for root to
appear in their initramfs scripts.  In 2.6.30 Commit

c751085943362143f84346d274e0011419c84202
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Sun Apr 12 20:06:56 2009 +0200

    PM/Hibernate: Wait for SCSI devices scan to complete during resume

Actually broke scsi_wait_scan because it renders
scsi_complete_async_scans() a nop for modular SCSI if you include
scsi_scans.h (which this module does).

The lack of bug reports is sufficient proof that this module is no
longer used.

Cc: Jeff Mahoney <jeffm@suse.de>
Cc: Dave Jones <davej@redhat.com>
Cc: maximilian attems <max@stro.at>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>

Conflicts:
	drivers/scsi/scsi_wait_scan.c