We did not take into account that xen_released_pages would be
used outside the initial E820 parsing code. As such we would
did not subtract from xen_released_pages the count of pages
that we had populated back (instead we just did a simple
extra_pages = released - populated).

The balloon driver uses xen_released_pages to set the initial
current_pages count.  If this is wrong (too low) then when a new
(higher) target is set, the balloon driver will request too many pages
from Xen."

This fixes errors such as:

(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (51 of 512)
during bootup and
free_memory            : 0

where the free_memory should be 128.
Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
[v1: Per David's review made the git commit better]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Some SR-IOV devices may use more than one bus number, but there is no real bridges
because that have internal routing mechanism. So need to check whether the bridge is
existing before using it.
Signed-off-by: NYang Zhang <yang.z.zhang@Intel.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

All of the bind_XYZ_to_irq do a quick lookup to see if the
event exists. And if it does, then the initialized IRQ number
is returned instead of initializing a new IRQ number.

This patch adds an extra logic to check that the type returned
is proper one and that there is an IRQ handler setup for it.

This patch has the benefit of being able to find drivers that
are doing something naught.

[v1: Enhanced based on Stefano's review]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

We need to make sure that those parameters are setup to be correct.
As such the value of 0 is deemed invalid and we find that we
bail out. The hypervisor sets by default all of them to be zero
and when the hypercall is done does a simple:

 a.value = d->arch.hvm_domain.params[a.index];

Which means that if the Xen toolstack forgot to setup the proper
HVM_PARAM_CONSOLE_EVTCHN (or the PFN one), we would get the
default value of 0 and use that.

CC: stable@kernel.org
Fixes-Oracle-Bug: 14091238
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

We weren't resetting the parameter to be passed in to a
known default. Nor were we checking the return value of
hvm_get_parameter.

CC: stable@kernel.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

All of the error paths are doing the same logic. In which
case we might as well collapse them in one path.

CC: stable@kernel.org
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

PV on HVM guests map GSIs into event channels. At restore time the
event channels are resumed by restore_pirqs.

Device drivers might try to register the same GSI again through ACPI at
restore time, but the GSI has already been mapped and bound by
restore_pirqs. This patch detects these situations and avoids
 mapping the same GSI multiple times.

Without this patch we get:
(XEN) irq.c:2235: dom4: pirq 23 or emuirq 28 already mapped
and waste a pirq.

CC: stable@kernel.org
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

If kzalloc() returns a NULL here, we pass a NULL to
xencons_disconnect_backend() which will cause an Oops.

Also I removed the __GFP_ZERO while I was at it since kzalloc() implies
__GFP_ZERO.

CC: stable@kernel.org
Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Currently, the memory target in the Xen selfballooning driver is mainly
driven by the value of "Committed_AS".  However, there are cases in
which it is desirable to assign additional memory to be available for
the kernel, e.g. for local caches (which are not covered by cleancache),
e.g. dcache and inode caches.

This adds an additional tunable in the selfballooning driver (accessible
via sysfs) which allows the user to specify an additional constant
amount of memory to be reserved by the selfballoning driver for the
local domain.
Signed-off-by: NJana Saout <jana@saout.de>
Acked-by: NDan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Add an ioctl to the /dev/xen/xenbus_backend device allowing the xenbus
backend to be started after the kernel has booted. This allows xenstore
to run in a different domain from the dom0.
Signed-off-by: NDaniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The git commit  1ff2b0c3
"xen: implement IRQ_WORK_VECTOR handler" added the functionality
to have a per-cpu "irqworkX" for the IPI APIC functionality.
However it missed the unbind when a vCPU is unplugged resulting
in an orphaned per-cpu interrupt line for unplugged vCPU:

  30:        216          0   xen-dyn-event     hvc_console
  31:        810          4   xen-dyn-event     eth0
  32:         29          0   xen-dyn-event     blkif
- 36:          0          0  xen-percpu-ipi       irqwork2
- 37:        287          0   xen-dyn-event     xenbus
+ 36:        287          0   xen-dyn-event     xenbus
 NMI:          0          0   Non-maskable interrupts
 LOC:          0          0   Local timer interrupts
 SPU:          0          0   Spurious interrupts
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

* stable/autoballoon.v5.2:
  xen/setup: update VA mapping when releasing memory during setup
  xen/setup: Combine the two hypercall functions - since they are quite similar.
  xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
  xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
  xen/p2m: An early bootup variant of set_phys_to_machine
  xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
  xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
  xen/p2m: Move code around to allow for better re-usage.

This patch is a significant performance improvement for the
m2p_override: about 6% using the gntdev device.

Each m2p_add/remove_override call issues a MULTI_grant_table_op and a
__flush_tlb_single if kmap_op != NULL.  Batching all the calls together
is a great performance benefit because it means issuing one hypercall
total rather than two hypercall per page.
If paravirt_lazy_mode is set PARAVIRT_LAZY_MMU, all these calls are
going to be batched together, otherwise they are issued one at a time.

Adding arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode around the
m2p_add/remove_override calls forces paravirt_lazy_mode to
PARAVIRT_LAZY_MMU, therefore makes sure that they are always batched.

However it is not safe to call arch_enter_lazy_mmu_mode if we are in
interrupt context or if we are already in PARAVIRT_LAZY_MMU mode, so
check for both conditions before doing so.

Changes in v4:
- rebased on 3.4-rc4: all the m2p_override users call gnttab_unmap_refs
and gnttab_map_refs;
- check whether we are in interrupt context and the lazy_mode we are in
before calling arch_enter/leave_lazy_mmu_mode.

Changes in v3:
- do not call arch_enter/leave_lazy_mmu_mode in xen_blkbk_unmap, that
can be called in interrupt context.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
[v5: s/int lazy/bool lazy/]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Provide the registration callback to call in the Xen's
ACPI sleep functionality. This means that during S3/S5
we make a hypercall XENPF_enter_acpi_sleep with the
proper PM1A/PM1B registers.

Based of Ke Yu's <ke.yu@intel.com> initial idea.
[ From http://xenbits.xensource.com/linux-2.6.18-xen.hg
change c68699484a65 ]

[v1: Added Copyright and license]
[v2: Added check if PM1A/B the 16-bits MSB contain something. The spec
     only uses 16-bits but might have more in future]
Signed-off-by: NLiang Tang <liang.tang@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Signed-off-by: NLin Ming <mlin@ss.pku.edu.cn>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Map native ipi vector to xen vector.
Implement apic ipi interface with xen_send_IPI_one.
Tested-by: NSteven Noonan <steven@uplinklabs.net>
Signed-off-by: NBen Guthro <ben@guthro.net>
Signed-off-by: NLin Ming <mlin@ss.pku.edu.cn>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

In xen_memory_setup(), if a page that is being released has a VA
mapping this must also be updated.  Otherwise, the page will be not
released completely -- it will still be referenced in Xen and won't be
freed util the mapping is removed and this prevents it from being
reallocated at a different PFN.

This was already being done for the ISA memory region in
xen_ident_map_ISA() but on many systems this was omitting a few pages
as many systems marked a few pages below the ISA memory region as
reserved in the e820 map.

This fixes errors such as:

(XEN) page_alloc.c:1148:d0 Over-allocation for domain 0: 2097153 > 2097152
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=0 memflags=0 (0 of 17)
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

They use the same set of arguments, so it is just the matter
of using the proper hypercall.
Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

When the Xen hypervisor boots a PV kernel it hands it two pieces
of information: nr_pages and a made up E820 entry.

The nr_pages value defines the range from zero to nr_pages of PFNs
which have a valid Machine Frame Number (MFN) underneath it. The
E820 mirrors that (with the VGA hole):
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 00000000000a0000 (usable)
 Xen: 00000000000a0000 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000080800000 (usable)

The fun comes when a PV guest that is run with a machine E820 - that
can either be the initial domain or a PCI PV guest, where the E820
looks like the normal thing:

BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 000000000009e000 (usable)
 Xen: 000000000009ec00 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000020000000 (usable)
 Xen: 0000000020000000 - 0000000020200000 (reserved)
 Xen: 0000000020200000 - 0000000040000000 (usable)
 Xen: 0000000040000000 - 0000000040200000 (reserved)
 Xen: 0000000040200000 - 00000000bad80000 (usable)
 Xen: 00000000bad80000 - 00000000badc9000 (ACPI NVS)
..
With that overlaying the nr_pages directly on the E820 does not
work as there are gaps and non-RAM regions that won't be used
by the memory allocator. The 'xen_release_chunk' helps with that
by punching holes in the P2M (PFN to MFN lookup tree) for those
regions and tells us that:

Freeing  20000-20200 pfn range: 512 pages freed
Freeing  40000-40200 pfn range: 512 pages freed
Freeing  bad80-badf4 pfn range: 116 pages freed
Freeing  badf6-bae7f pfn range: 137 pages freed
Freeing  bb000-100000 pfn range: 282624 pages freed
Released 283999 pages of unused memory

Those 283999 pages are subtracted from the nr_pages and are returned
to the hypervisor. The end result is that the initial domain
boots with 1GB less memory as the nr_pages has been subtracted by
the amount of pages residing within the PCI hole. It can balloon up
to that if desired using 'xl mem-set 0 8092', but the balloon driver
is not always compiled in for the initial domain.

This patch, implements the populate hypercall (XENMEM_populate_physmap)
which increases the the domain with the same amount of pages that
were released.

The other solution (that did not work) was to transplant the MFN in
the P2M tree - the ones that were going to be freed were put in
the E820_RAM regions past the nr_pages. But the modifications to the
M2P array (the other side of creating PTEs) were not carried away.
As the hypervisor is the only one capable of modifying that and the
only two hypercalls that would do this are: the update_va_mapping
(which won't work, as during initial bootup only PFNs up to nr_pages
are mapped in the guest) or via the populate hypercall.

The end result is that the kernel can now boot with the
nr_pages without having to subtract the 283999 pages.

On a 8GB machine, with various dom0_mem= parameters this is what we get:

no dom0_mem
-Memory: 6485264k/9435136k available (5817k kernel code, 1136060k absent, 1813812k reserved, 2899k data, 696k init)
+Memory: 7619036k/9435136k available (5817k kernel code, 1136060k absent, 680040k reserved, 2899k data, 696k init)

dom0_mem=3G
-Memory: 2616536k/9435136k available (5817k kernel code, 1136060k absent, 5682540k reserved, 2899k data, 696k init)
+Memory: 2703776k/9435136k available (5817k kernel code, 1136060k absent, 5595300k reserved, 2899k data, 696k init)

dom0_mem=max:3G
-Memory: 2696732k/4281724k available (5817k kernel code, 1136060k absent, 448932k reserved, 2899k data, 696k init)
+Memory: 2702204k/4281724k available (5817k kernel code, 1136060k absent, 443460k reserved, 2899k data, 696k init)

And the 'xm list' or 'xl list' now reflect what the dom0_mem=
argument is.
Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
[v2: Use populate hypercall]
[v3: Remove debug printks]
[v4: Simplify code]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Otherwise we can get these meaningless:
Freeing  bad80-badf4 pfn range: 0 pages freed

We also can do this for the summary ones - no point of printing
"Set 0 page(s) to 1-1 mapping"
Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
[v1: Extended to the summary printks]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Rather than just leaking pages that can't be freed at the point where
access permission for the backend domain gets revoked, put them on a
list and run a timer to (infrequently) retry freeing them. (This can
particularly happen when unloading a frontend driver when devices are
still present, and the backend still has them in non-closed state or
hasn't finished closing them yet.)
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Move the code from Xen to debugfs to make the code common
for other users as well.
Accked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSrivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: NSuzuki Poulose <suzuki@in.ibm.com>
[v1: Fixed rebase issues]
[v2: Fixed PPC compile issues]
Signed-off-by: NRaghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Pull ARM fixes from Russell King:
 "Nothing too disasterous, the biggest thing being the removal of the
  regulator support for vcore in the AMBA driver; only one SoC was using
  this and it got broken during the last merge window, which then
  started causing problems for other people.  Mutual agreement was
  reached for it to be removed."

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7386/1: jump_label: fixup for rename to static_key
  ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE
  ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU
  ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus
  ARM: 7383/1: nommu: populate vectors page from paging_init
  ARM: 7381/1: nommu: fix typo in mm/Kconfig
  ARM: 7380/1: DT: do not add a zero-sized memory property
  ARM: 7379/1: DT: fix atags_to_fdt() second call site
  ARM: 7366/3: amba: Remove AMBA level regulator support
  ARM: 7377/1: vic: re-read status register before dispatching each IRQ handler
  ARM: 7368/1: fault.c: correct how the tsk->[maj|min]_flt gets incremented

The 'max' range needs to be unsigned, since the size of the user address
space is bigger than 2GB.

We know that 'count' is positive in 'long' (that is checked in the
caller), so we will truncate 'max' down to something that fits in a
signed long, but before we actually do that, that comparison needs to be
done in unsigned.

Bug introduced in commit 92ae03f2 ("x86: merge 32/64-bit versions of
'strncpy_from_user()' and speed it up").  On x86-64 you can't trigger
this, since the user address space is much smaller than 63 bits, and on
x86-32 it works in practice, since you would seldom hit the strncpy
limits anyway.

I had actually tested the corner-cases, I had only tested them on
x86-64.  Besides, I had only worried about the case of a pointer *close*
to the end of the address space, rather than really far away from it ;)

This also changes the "we hit the user-specified maximum" to return
'res', for the trivial reason that gcc seems to generate better code
that way.  'res' and 'count' are the same in that case, so it really
doesn't matter which one we return.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

c5905afb ("static keys: Introduce 'struct static_key'...") renamed
struct jump_label_key to struct static_key.  Fixup ARM for this to
eliminate these build warnings:

  include/linux/jump_label.h:113:2:
  warning: passing argument 1 of 'arch_static_branch' from incompatible pointer type
  include/asm/jump_label.h:17:82:
  note: expected 'struct jump_label_key *' but argument is of type 'struct static_key *'
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently when ThumbEE is not enabled (!CONFIG_ARM_THUMBEE) the ThumbEE
register states are not saved/restored at context switch. The default state
of the ThumbEE Ctrl register (TEECR) allows userspace accesses to the
ThumbEE Base Handler register (TEEHBR). This can cause unexpected behaviour
when people use ThumbEE on !CONFIG_ARM_THUMBEE kernels, as well as allowing
covert communication - eg between userspace tasks running inside chroot
jails.

This patch sets up TEECR in order to prevent user-space access to TEEHBR
when !CONFIG_ARM_THUMBEE. In this case, tasks are sent SIGILL if they try to
access TEEHBR.

Cc: stable@vger.kernel.org
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJonathan Austin <jonathan.austin@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If a bank of memory spanning the 4GB boundary is added on a !CONFIG_LPAE
kernel then we will hang early during boot since the memory bank will
have wrapped around to zero.

This patch truncates memory banks for !LPAE configurations when the end
address is not representable in 32 bits.
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

During booting of cpu1, there is a short window where cpu1
is online, but not active where cpu1 is occupied by waiting
to become active. If cpu0 then decides to schedule something
on cpu1 and wait for it to complete, before cpu0 has set
cpu1 active, we have a deadlock.

Typically it's this CPU frequency transition that happens at
this time, so let's just not wait for it to happen, it will
happen whenever the CPU eventually comes online instead.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@kernel.org
Signed-off-by: NJonas Aaberg <jonas.aberg@stericsson.com>
Reviewed-by: NRickard Andersson <rickard.andersson@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 26f41062 ("PCI: check for pci bar restore completion and
retry") attempted to address problems with PCI BAR restoration on
systems where FLR had not been completed before pci_restore_state() was
called, but it did that in an utterly wrong way.

First off, instead of retrying the writes for the BAR registers only, it
did that for all of the PCI config space of the device, including the
status register (whose value after the write quite obviously need not be
the same as the written one).  Second, it added arbitrary delay to
pci_restore_state() even for systems where the PCI config space
restoration was successful at first attempt.  Finally, the mdelay(10) it
added to every iteration of the writing loop was way too much of a delay
for any reasonable device.

All of this actually caused resume failures for some devices on Mikko's
system.

To fix the regression, make pci_restore_state() only retry the writes
for BAR registers and only wait if the first read from the register
doesn't return the written value.  Additionaly, make it wait for 1 ms,
instead of 10 ms, after every failing attempt to write into config
space.
Reported-by: NMikko Vinni <mmvinni@yahoo.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull "ARM: a few more SoC fixes for 3.4-rc" from Olof Johansson:
 - A handful of warning and build fixes for Qualcomm MSM
 - Build/warning and bug fixes for Samsung Exynos
 - A fix from Rob Herring that removes misplaced interrupt-parent
   properties from a few device trees
 - A fix to OMAP dealing with cpufreq build errors, removing some of the
   offending code since it was redundant anyway

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: OMAP: clock: cleanup CPUfreq leftovers, fix build errors
  ARM: dts: remove blank interrupt-parent properties
  ARM: EXYNOS: Fix Kconfig dependencies for device tree enabled machine files
  ARM: EXYNOS: Remove broken config values for touchscren for NURI board
  ARM: EXYNOS: set fix xusbxti clock for NURI and Universal210 boards
  ARM: EXYNOS: fix regulator name for NURI board
  ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL
  ARM: msm: Fix section mismatches in proc_comm.c
  video: msm: Fix section mismatches in mddi.c
  arm: msm: trout: fix compile failure
  arm: msm: halibut: remove unneeded fixup
  ARM: EXYNOS: Add PDMA and MDMA physical base address defines
  ARM: S5PV210: Fix compiler warning in dma.c file
  ARM: EXYNOS: Fix compile error in exynos5250-cpufreq.c
  ARM: EXYNOS: Add missing definition for IRQ_I2S0
  ARM: S5PV210: fix unused LDO supply field from wm8994_pdata

Pull another round of sound fixes from Takashi Iwai:
 "A few regression fixes for Realtek HD-audio codecs, mainly specific to
  some laptop models."

* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda/realtek - Fix mem leak (and rid us of trailing whitespace).
  ALSA: hda/realtek - Add quirk for Mac Pro 5,1 machines
  ALSA: hda/realtek - Add a fixup entry for Acer Aspire 8940G
  ALSA: hda/realtek - Fix GPIO1 setup for Acer Aspire 4930 & co
  ALSA: hda/realtek - Add a few ALC882 model strings back

Commit 18a4d0a2 ("[SCSI] Handle disk devices which can not process
medium access commands") introduced a bug in which we would attempt to
dereference the scsi driver even when the device had no ULD attached.

Ensure that a driver is registered and make the driver accessor function
more resilient to errors during device discovery.
Reported-by: NElric Fu <elricfu1@gmail.com>
Reported-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge branch 'v3.4-samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes

* 'v3.4-samsung-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  ARM: EXYNOS: Fix Kconfig dependencies for device tree enabled machine files
  ARM: EXYNOS: Remove broken config values for touchscren for NURI board
  ARM: EXYNOS: set fix xusbxti clock for NURI and Universal210 boards
  ARM: EXYNOS: fix regulator name for NURI board
  ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL
  ARM: EXYNOS: Add PDMA and MDMA physical base address defines
  ARM: S5PV210: Fix compiler warning in dma.c file
  ARM: EXYNOS: Fix compile error in exynos5250-cpufreq.c
  ARM: EXYNOS: Add missing definition for IRQ_I2S0
  ARM: S5PV210: fix unused LDO supply field from wm8994_pdata

Now that we have OPP layer, and OMAP CPUfreq driver is using it, we no
longer need/use the clock framework code for filling up CPUfreq
tables.  Remove it.

Removing this code also eliminates build errors when CPU_FREQ_TABLE
support is not enabled.

Thanks to Russell King for pointing out the parts I missed under
plat-omap in the original version and also pointing out the build
errors when CPUFREQ_TABLE support was not enabled.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

These were incorrectly introduced and can cause problems for of_irq_init.

The correct way to define a root controller is no interrupt-parent set at
all or the interrupt-parent is set to the root controller itself when
inherited from a parent node.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Tested-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

From David Brown:
  "Here are some fixes for msm that fix problems caused by the latest
   ARM code.  The ones from Daniel remove unneeded fixups that now
   cause compilation failures.  Mine fix section mismatches, that were
   incompletely fixed earlier."

* 'msm-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm:
  ARM: msm: Fix section mismatches in proc_comm.c
  video: msm: Fix section mismatches in mddi.c
  arm: msm: trout: fix compile failure
  arm: msm: halibut: remove unneeded fixup

Add config dependency for Exynos4 and Exynos5 device tree enabled machine
files on config options ARCH_EXYNOS4 and ARCH_EXYNOS5 respectively.
Enabling machine support without proper ARCH support enabled is incorrect.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Pull perf tool fixes from Ingo Molnar.

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf kvm: Finding struct machine fails for PERF_RECORD_MMAP
  perf annotate: Validate addr in symbol__inc_addr_samples
  perf hists browser: Fix NULL deref in hists browsing code
  perf hists: Catch and handle out-of-date hist entry maps.
  perf annotate: Fix hist decay
  perf top: Add intel_idle to the skip list

GCC's NULL is actually __null, which allows detecting some questionable
NULL usage and warn about it.  Moreover each platform/compiler should
have its own stddef.h anyway (which is different from linux/stddef.h).

So there's no good reason to leak kernel's NULL to userspace and
override what the compiler provides.
Signed-off-by: NLuboš Luňák <l.lunak@suse.cz>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>