Jason Gunthorpe reports a build failure when ARM_PATCH_PHYS_VIRT is
not defined:

In file included from arch/arm/include/asm/page.h:163:0,
                 from include/linux/mm_types.h:16,
                 from include/linux/sched.h:24,
                 from arch/arm/kernel/asm-offsets.c:13:
arch/arm/include/asm/memory.h: In function '__virt_to_phys':
arch/arm/include/asm/memory.h:244:40: error: 'PHYS_OFFSET' undeclared (first use in this function)
arch/arm/include/asm/memory.h:244:40: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/include/asm/memory.h: In function '__phys_to_virt':
arch/arm/include/asm/memory.h:249:13: error: 'PHYS_OFFSET' undeclared (first use in this function)

Fixes: ca5a45c0 ("ARM: mm: use phys_addr_t appropriately in p2v and v2p conversions")
Tested-By: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

A guest can cause a BUG_ON() leading to a host kernel crash.
When the guest writes to the ICR to request an IPI, while in x2apic
mode the following things happen, the destination is read from
ICR2, which is a register that the guest can control.

kvm_irq_delivery_to_apic_fast uses the high 16 bits of ICR2 as the
cluster id.  A BUG_ON is triggered, which is a protection against
accessing map->logical_map with an out-of-bounds access and manages
to avoid that anything really unsafe occurs.

The logic in the code is correct from real HW point of view. The problem
is that KVM supports only one cluster with ID 0 in clustered mode, but
the code that has the bug does not take this into account.
Reported-by: NLars Bull <larsbull@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the
potential to corrupt kernel memory if userspace provides an address that
is at the end of a page.  This patches concerts those functions to use
kvm_write_guest_cached and kvm_read_guest_cached.  It also checks the
vapic_address specified by userspace during ioctl processing and returns
an error to userspace if the address is not a valid GPA.

This is generally not guest triggerable, because the required write is
done by firmware that runs before the guest.  Also, it only affects AMD
processors and oldish Intel that do not have the FlexPriority feature
(unless you disable FlexPriority, of course; then newer processors are
also affected).

Fixes: b93463aa ('KVM: Accelerated apic support')
Reported-by: NAndrew Honig <ahonig@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAndrew Honig <ahonig@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Under guest controllable circumstances apic_get_tmcct will execute a
divide by zero and cause a crash.  If the guest cpuid support
tsc deadline timers and performs the following sequence of requests
the host will crash.
- Set the mode to periodic
- Set the TMICT to 0
- Set the mode bits to 11 (neither periodic, nor one shot, nor tsc deadline)
- Set the TMICT to non-zero.
Then the lapic_timer.period will be 0, but the TMICT will not be.  If the
guest then reads from the TMCCT then the host will perform a divide by 0.

This patch ensures that if the lapic_timer.period is 0, then the division
does not occur.
Reported-by: NAndrew Honig <ahonig@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAndrew Honig <ahonig@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The Allwinner A31 uses the ARM GIC as its internal interrupts controller. The
GIC can work on several interrupt triggers, and the A31 was actually setting it
up to use a rising edge as a trigger, while it was actually a level high
trigger, leading to some interrupts that would be completely ignored if the
edge was missed.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org # 3.12+
Signed-off-by: NOlof Johansson <olof@lixom.net>

The Allwinner A20 uses the ARM GIC as its internal interrupts controller. The
GIC can work on several interrupt triggers, and the A20 was actually setting it
up to use a rising edge as a trigger, while it was actually a level high
trigger, leading to some interrupts that would be completely ignored if the
edge was missed.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org #3.12+
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add a missing break to the switch in tegra_init_fuse() which determines
which SoC the code is running on. This prevents the Tegra30+ fuse
handling code from running on Tegra20.

Fixes: 3bd1ae57 ("ARM: tegra: add fuses as device randomness")
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Erratum 71 of PXA270M Processor Family Specification Update
(April 19, 2010) explains that watchdog reset time is just
8us insead of 10ms in EMTS.

If SDRAM is not reset, it causes memory bus congestion and
the device hangs. We put SDRAM in selfresh mode before watchdog
reset, removing potential freezes.

Without this patch PXA270-based ICP DAS LP-8x4x hangs after up to 40
reboots. With this patch it has successfully rebooted 500 times.
Signed-off-by: NSergei Ianovich <ynvich@gmail.com>
Tested-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NOlof Johansson <olof@lixom.net>

When converting from tosa-keyboard driver to matrix keyboard, tosa keys
received extra 1 column shift. Replace that with correct values to make
keyboard work again.

Fixes: f69a6548 ('[ARM] pxa/tosa: make use of the matrix keypad driver')
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NOlof Johansson <olof@lixom.net>

UEFI time services are often broken once we're in virtual mode. We were
already refusing to use them on 64-bit systems, but it turns out that
they're also broken on some 32-bit firmware, including the Dell Venue.
Disable them for now, we can revisit once we have the 1:1 mappings code
incorporated.
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
Link: http://lkml.kernel.org/r/1385754283-2464-1-git-send-email-matthew.garrett@nebula.com
Cc: <stable@vger.kernel.org>
Cc: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Due to the cross dependencies between hwmod for automanaged device
information for OMAP and dts node definitions, we can run into scenarios
where the dts node is defined, however it's hwmod entry is yet to be
added. In these cases:
a) omap_device does not register a pm_domain (since it cannot find
   hwmod entry).
b) driver does not know about (a), does a pm_runtime_get_sync which
   never fails
c) It then tries to do some operation on the device (such as read the
  revision register (as part of probe) without clock or adequate OMAP
  generic PM operation performed for enabling the module.

This causes a crash such as that reported in:
https://bugzilla.kernel.org/show_bug.cgi?id=66441

When 'ti,hwmod' is provided in dt node, it is expected that the device
will not function without the OMAP's power automanagement. Hence, when
we hit a fail condition (due to hwmod entries not present or other
similar scenario), fail at pm_domain level due to lack of data, provide
enough information for it to be fixed, however, it allows for the driver
to take appropriate measures to prevent crash.
Reported-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

The SGI UV tlb shootdown code panics the system with a NULL
pointer deference if 'nobau' is specified on the boot
commandline.

uv_flush_tlb_other() gets called for every flush, whether the
BAU is disabled or not.  It should not be keeping the s_enters
statistic while the BAU is disabled.

The panic occurs because during initialization
init_per_cpu_tunables() does not set the bcp->statp pointer if
'nobau' was specified.
Signed-off-by: NCliff Wickman <cpw@sgi.com>
Cc: <stable@vger.kernel.org> # 3.12.x
Link: http://lkml.kernel.org/r/E1VnzBi-0005yF-MU@eag09.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Treat both negative and zero return values from clk_round_rate() as
errors.  This is needed since subsequent patches will convert
clk_round_rate()'s return value to be an unsigned type, rather than a
signed type, since some clock sources can generate rates higher than
(2^31)-1 Hz.

Eventually, when calling clk_round_rate(), only a return value of zero
will be considered a error.  All other values will be considered valid
rates.  The comparison against values less than 0 is kept to preserve
the correct behavior in the meantime.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Håvard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>

This patch proposes to remove the use of the IRQF_DISABLED flag

It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>

The power management has a section mismatch which leads to the following
warning during compilation:

WARNING: arch/avr32/mach-at32ap/built-in.o(.text+0x16d4): Section
mismatch in reference from the function avr32_pm_offset() to the
function .init.text:pm_exception()
The function avr32_pm_offset() references
the function __init pm_exception().
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Acked-by: NHans-Christian Egtvedt <hegtvedt@cisco.com>

This patch removes CONFIG_MTD_PARTITIONS in config files for avr32.
Because CONFIG_MTD_PARTITIONS was removed by commit
6a8a98b2.
Signed-off-by: NEunbong Song <eunb.song@samsung.com>
Acked-by: NHans-Christian Egtvedt <hegtvedt@cisco.com>

The current logic sets the kdump base to min of 2G or ppc64_rma_size/2.
On PowerNV kernel the first memory block 'memory@0' can be very large,
equal to the DIMM size with ppc64_rma_size value capped to 1G. Hence on
PowerNV, kdump base is set to 512M resulting kdump to fail while allocating
paca array. This is because, paca need its memory from RMA region capped
at 256M (see allocate_pacas()).

This patch lowers the kdump base cap to 128M so that kdump kernel can
successfully get memory below 256M for paca allocation.
Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

I have recently found out that no iommu_groups could be found under
/sys/ on a P8. That prevents PCI passthrough from working.

During my investigation, I found out there seems to be a missing
iommu_register_group for PHB3. The following patch seems to fix the
problem. After applying it, I see iommu_groups under
/sys/kernel/iommu_groups/, and can also bind vfio-pci to an adapter,
which gives me a device at /dev/vfio/.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The bestcomm driver has been moved to drivers/dma, so to select
this driver by default additionally CONFIG_DMADEVICES has to be
enabled. Currently it is not enabled in the config despite existing
CONFIG_PPC_BESTCOMM=y in the config files. Fix it.
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

At least some distros expect it these days; turn it on. Also, random
churn from doing a savedefconfig for the first time in a year or so.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

In pte_alloc_one(), pgtable_page_ctor() is passed an address that has
not been converted by page_address() to the newly allocated PTE page.

When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor()
with an address to the PTE page that has been converted by page_address().
The mismatch in the PTE's page address causes pgtable_page_dtor() to access
invalid memory, so resources for that PTE (such as the page lock) is not
properly cleaned up.

On PPC32, only SMP kernels are affected.

On PPC64, only SMP kernels with 4K page size are affected.

This bug was introduced by commit d614bb04
"powerpc: Move the pte free routines from common header".

On a preempt-rt kernel, a spinlock is dynamically allocated for each
PTE in pgtable_page_ctor().  When the PTE is freed, calling
pgtable_page_dtor() with a mismatched page address causes a memory leak,
as the pointer to the PTE's spinlock is bogus.

On mainline, there isn't any immediately obvious symptoms, but the
problem still exists here.

Fixes: d614bb04 "powerpc: Move the pte free routes from common header"
Cc: Paul Mackerras <paulus@samba.org>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-stable <stable@vger.kernel.org> # v3.10+
Signed-off-by: NHong H. Pham <hong.pham@windriver.com>
Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Allocate enough memory for the ocm_block structure, not just a pointer
to it.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

A kernel configured with PPC_EARLY_DEBUG_BOOTX=y but PPC_PMAC=n and
PPC_MAPLE=n will fail to link:

  btext.c:(.text+0x2d0fc): undefined reference to `.rmci_off'
  btext.c:(.text+0x2d214): undefined reference to `.rmci_on'

Fix it by making the build of rmci_on/off() depend on
PPC_EARLY_DEBUG_BOOTX, which also enable the only code that uses them.
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

In checkin

    5551a34e x86-64, build: Always pass in -mno-sse

we unconditionally added -mno-sse to the main build, to keep newer
compilers from generating SSE instructions from autovectorization.
However, this did not extend to the special environments
(arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode/rm).
Add -mno-sse to the compiler command line for these environments, and
add -mno-mmx to all the environments as well, as we don't want a
compiler to generate MMX code either.

This patch also removes a $(cc-option) call for -m32, since we have
long since stopped supporting compilers too old for the -m32 option,
and in fact hardcode it in other places in the Makefiles.
Reported-by: NKevin B. Smith <kevin.b.smith@intel.com>
Cc: Sunil K. Pandey <sunil.k.pandey@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: H. J. Lu <hjl.tools@gmail.com>
Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org
Cc: <stable@vger.kernel.org> # build fix only

The __do_cache_op function operates with a 'chunk' size of one page
but fails to limit the size of the final chunk so as to not exceed
the specified memory region. Fix this.

Cc: <stable@vger.kernel.org>
Reported-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJon Medhurst <tixy@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch fixes corner case when (fp + 4) overflows unsigned long,
for example: fp = 0xFFFFFFFF -> fp + 4 == 3.

Cc: <stable@vger.kernel.org>
Signed-off-by: NKonstantin Khlebnikov <k.khlebnikov@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

get_wchan() is lockless. Task may wakeup at any time and change its own stack,
thus each next stack frame may be overwritten and filled with random stuff.

/proc/$pid/stack interface had been disabled for non-current tasks, see [1]
But 'wchan' still allows to trigger stack frame unwinding on volatile stack.

This patch fixes oops in unwind_frame() by adding stack pointer validation on
each step (as x86 code do), unwind_frame() already checks frame pointer.

Also I've found another report of this oops on stackoverflow (irony).

Link: http://www.spinics.net/lists/arm-kernel/msg110589.html [1]
Link: http://stackoverflow.com/questions/18479894/unwind-frame-cause-a-kernel-paging-error

Cc: <stable@vger.kernel.org>
Signed-off-by: NKonstantin Khlebnikov <k.khlebnikov@samsung.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

To get updated __pv_phys_offset, setup_dma_zone() needs to be
called after early_paging_init().

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Current code is using PHYS_OFFSET to calculate the arm_dma_limit which
will lead to wrong calculations in cases where PHYS_OFFSET is updated
runtime.

So fix the code by using __pv_phys_offset instead of PHYS_OFFSET.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Peter reports that OMAP audio broke with the recent fix for these
checks, caused by OMAP audio using a 64-bit DMA mask.  We should
allow 64-bit DMA masks even with 32-bit dma_addr_t if we can be sure
the amount of RAM we have won't allow the 32-bit dma_addr_t to
overflow.  Unfortunately, the checks to detect overflow were not
correct.
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

commit dc75925d(OMAP: hwmod: Fix the missing braces) introduced
missing braces, however, we just set return result if clk_get fail
and we populate the error pointer in clk pointer and pass it along to
clk_prepare. This is wrong. The intent seems to be retry remaining
clocks if they are available and warn the ones we cant find clks for.

With the current logic, we see the following crash:
omap_hwmod: l3_main: cannot clk_get interface_clk emac_ick
Unable to handle kernel NULL pointer dereference at virtual address 00000032
pgd = c0004000
[00000032] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00044-gcc9fd5a-dirty #19
task: ce0c3440 ti: ce0c4000 task.ti: ce0c4000
PC is at __clk_prepare+0x10/0x74
LR is at clk_prepare+0x14/0x24
  <snip>
[<c044d59c>] (__clk_prepare+0x10/0x74) from [<c044d9b0>] (clk_prepare+0x14/0x24)
[<c044d9b0>] (clk_prepare+0x14/0x24) from [<c077d8c4>] (_init+0x24c/0x3bc)
[<c077d8c4>] (_init+0x24c/0x3bc) from [<c0027328>] (omap_hwmod_for_each+0x34/0x5c)
[<c0027328>] (omap_hwmod_for_each+0x34/0x5c) from [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40)
[<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) from [<c0008928>] (do_one_initcall+0x38/0x168)
[<c0008928>] (do_one_initcall+0x38/0x168) from [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc)
[<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) from [<c0521064>] (kernel_init+0x8/0x110)
[<c0521064>] (kernel_init+0x8/0x110) from [<c000e568>] (ret_from_fork+0x14/0x2c)
Code: e92d4038 e2504000 01a05004 0a000005 (e5943034)

So, just warn and continue instead of proceeding and crashing, with
missing clock nodes/bad data, we will eventually fail, however we
should now have enough information to identify the culprit.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.

RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
Fixes: de231388 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
the hwmod's sysc_cache will always contain SOFTRESET bit set
so all further writes to sysconfig using this cache will initiate
a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
platforms that have RESET_DONE status in the SYSSTATUS register and
so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
It is not a problem for OMAP4 like platforms that indicate RESET
completion by clearing the SOFTRESET bit in the SYSCONFIG register.

This repeated SOFTRESET is undesired and was the root cause of
USB host issues on OMAP3 platforms when hwmod was allowed to do the
SOFTRESET for the USB Host module.

To fix this we clear the SOFTRESET bit and update the sysconfig
register + sysc_cache using write_sysconfig().
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
[paul@pwsan.com: renamed _clr_softreset() to _clear_softreset()]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Without this, the USB devices are sometimes not detected on OMAP4 Panda
with u-boot v2013.10.

Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.

RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Reported-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
Acked-by: NBenoît Cousson <bcousson@baylibre.com>
Fixes: af88fa9a ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP4")
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

the 'soc' node in the common .dtsi for MPC5121 has an '#interrupt-cells'
property although this node is not an interrupt controller

remove this erroneously placed property because starting with v3.13-rc1
lookup and resolution of 'interrupts' specs for peripherals gets misled,
emits 'no irq domain found' WARN() messages and breaks the boot process

  irq: no irq domain found for /soc@80000000 !
  ------------[ cut here ]------------
  WARNING: at drivers/of/platform.c:171
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper Tainted: G        W    3.13.0-rc1-00001-g8a66234 #8
  task: df823bb0 ti: df834000 task.ti: df834000
  NIP: c02b5190 LR: c02b5180 CTR: c01cf4e0
  REGS: df835c50 TRAP: 0700   Tainted: G        W     (3.13.0-rc1-00001-g8a66234)
  MSR: 00029032 <EE,ME,IR,DR,RI>  CR: 229a9d42  XER: 20000000

  GPR00: c02b5180 df835d00 df823bb0 00000000 00000000 df835b18 ffffffff 00000308
  GPR08: c0479cc0 c0480000 c0479cc0 00000308 00000308 00000000 c00040fc 00000000
  GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 df850880
  GPR24: df84d670 00000000 00000001 df8561a0 dffffccc df85089c 00000020 00000001
  NIP [c02b5190] of_device_alloc+0xf4/0x1a0
  LR [c02b5180] of_device_alloc+0xe4/0x1a0
  Call Trace:
  [df835d00] [c02b5180] of_device_alloc+0xe4/0x1a0 (unreliable)
  [df835d50] [c02b5278] of_platform_device_create_pdata+0x3c/0xc8
  [df835d70] [c02b53fc] of_platform_bus_create+0xf8/0x170
  [df835dc0] [c02b5448] of_platform_bus_create+0x144/0x170
  [df835e10] [c02b55a8] of_platform_bus_probe+0x98/0xe8
  [df835e30] [c0437508] mpc512x_init+0x28/0x1c4
  [df835e70] [c0435de8] ppc_init+0x4c/0x60
  [df835e80] [c0003b28] do_one_initcall+0x150/0x1a4
  [df835ef0] [c0432048] kernel_init_freeable+0x114/0x1c0
  [df835f30] [c0004114] kernel_init+0x18/0x124
  [df835f40] [c000e910] ret_from_kernel_thread+0x5c/0x64
  Instruction dump:
  409effd4 57c9103a 57de2834 7c89f050 7f83e378 7c972214 7f45d378 48001f55
  7c63d278 7c630034 5463d97e 687a0001 <0f1a0000> 2f990000 387b0010 939b0098
  ---[ end trace 2257f10e5a20cbdd ]---

  ...
  irq: no irq domain found for /soc@80000000 !
  fsl-diu-fb 80002100.display: could not get DIU IRQ
  fsl-diu-fb: probe of 80002100.display failed with error -22
  irq: no irq domain found for /soc@80000000 !
  mpc512x_dma 80014000.dma: Error mapping IRQ!
  mpc512x_dma: probe of 80014000.dma failed with error -22
  ...
  irq: no irq domain found for /soc@80000000 !
  fs_enet: probe of 80002800.ethernet failed with error -22
  ...
  irq: no irq domain found for /soc@80000000 !
  mpc5121-rtc 80000a00.rtc: mpc5121_rtc_probe: could not request irq: 0
  mpc5121-rtc: probe of 80000a00.rtc failed with error -22
  ...

Cc: Anatolij Gustschin <agust@denx.de>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: devicetree@vger.kernel.org
Signed-off-by: NGerhard Sittig <gsi@denx.de>
Signed-off-by: NAnatolij Gustschin <agust@denx.de>

Commit 7ce93f31 (ARM: OMAP2+: Fix more missing data for omap3.dtsi file)
fixed missing device tree data for omaps, but did not account for some of the
hardware modules being inaccessible for secure omaps. This causes the
following error on secure omaps:

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0c5048
SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.13.0-rc2+ #446
task: ce057b40 ti: ce058000 task.ti: ce058000
PC is at omap_aes_dma_stop+0x24/0x3c
LR is at omap_aes_probe+0x1cc/0x584
   psr: 60000113
sp : ce059e20  ip : ce0b4ee0  fp : 00000000
r10: c0573ae8  r9 : c0749508  r8 : 00000000
r7 : ce0b4e00  r6 : 00000000  r5 : ce0b4e10  r4 : ce274890
r3 : fa0c5048  r2 : 00000048  r1 : 0000002c  r0 : ce274890
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xce058248)
Stack: (0xce059e20 to 0xce05a000)
9e20: c0749508 0000a1ff 00000000 c016cd8c c06b5a06 ce2a45f0 ce2a4570 ce0b5fb0
9e40: 00000000 480c5000 480c504f c0abe4e4 00000200 00000000 00000000 00000000
9e60: ce0b4e10 ce0b4e10 c082da3c c082da3c c02b8c70 c077c610 c0749508 00000000
9e80: 00000000 c02b9e7c c02b9e64 ce0b4e10 00000000 c02b8b20 ce0b4e10 ce0b4e44
9ea0: c082da3c c02b8cd8 00000000 ce059eb8 c082da3c c02b7408 ce079edc ce0b1a34
9ec0: c082da3c c082da3c ce2a0280 00000000 c08158d8 c02b8358 c0663405 c0663405
9ee0: 00000073 c082da3c c079e4e8 c07ab3bc c0844340 c02b9334 00000000 00000006
9f00: c079e4e8 c0008920 c067f6bf c0ac7c6b 00000000 c0712e28 00000000 00000000
9f20: c0712e38 ce059f38 00000093 c0ac7c82 00000000 c0058994 00000000 c07130e8
9f40: c07127b8 00000093 00000006 00000006 00000001 00000006 00000006 c079e4e8
9f60: c07ab3bc c0844340 00000093 c0749508 c079e4f4 c0749c64 00000006 00000006
9f80: c0749508 00000000 00000000 c0517e2c 00000000 00000000 00000000 00000000
9fa0: 00000000 c0517e34 00000000 c000dfb8 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
(omap_aes_probe+0x1cc/0x584)
(platform_drv_probe+0x18/0x48)
(driver_probe_device+0xb0/0x200)
(__driver_attach+0x68/0x8c)
(bus_for_each_dev+0x50/0x88)
(bus_add_driver+0xcc/0x1c8)
(driver_register+0x9c/0xe0)
(do_one_initcall+0x98/0x140)
(kernel_init_freeable+0x16c/0x23c)
(kernel_init+0x8/0x100)
(ret_from_fork+0x14/0x3c)
Code: e1811002 e5932020 e590300c e0833002 (e593c000)

Let's fix the issue by adding omap34xx-hs.dtsi and omap36xx-hs.dtsi and make
n900, n9 and n950 to use them. This way we have the aes, sham and timer12
disabled for secure devices the same way legacy booting does based on the
omap34xx_gp_hwmod_ocp_ifs and omap36xx_gp_hwmod_ocp_ifs arrays in
omap_hwmod_3xxx_data.c.
Reported-by: NSebastian Reichel <sre@debian.org>
Acked-By: NSebastian Reichel <sre@debian.org>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The am3517 is wrongly booting as omap3 which means that the am3517
specific devices like Ethernet won't work when booted with device
tree. Now with the new devices defined in am3517.dtsi, let's use
that instead of the omap3.dtsi, and add a separate machine entry
for am3517 so am3517-evm can use it.
Signed-off-by: NNishanth Menon <nm@ti.com>
[tony@atomide.com: updated comments and fixed build without omap3]
Signed-off-by: NTony Lindgren <tony@atomide.com>

On am3517 there are some extra devices compared to omap3.dtsi that
we currently have not defined. Let's fix that by adding am3517.dtsi
file.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We have some device tree properties where the ti,hwmod have multiple
values:

am33xx.dtsi:	ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
am4372.dtsi:	ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
dra7.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2";
omap3.dtsi:	ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
omap3.dtsi:	ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
omap4.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
omap5.dtsi:	ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";

That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.

So they should all be fixed up to be separate devices in the .dts files.

We also have the related data removed for at least omap4 in commit
3b9b1015 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.

So we need to fix two bugs:

1. We are only checking the first entry of the ti,hwmods property

   This means that we're only initializing the first hwmods entry
   instead of the ones listed in the ti,hwmods property.

2. We are only checking the child nodes, not the nodes themselves

   This means that anything listed at OCP level is currently just
   ignored and unitialized and at least the omap4 case, with the
   legacy data missing from the hwmod.

Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.

While at it, let's also add some warnings for the bad data so it's
easier to fix.

Cc: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Modify the value of PMD_SECT_PROT_NONE to match that of PTE_NONE. This
should have been in commit 3676f9ef (Move PTE_PROT_NONE higher up).
Signed-off-by: NSteve Capper <steve.capper@linaro.org>
Cc: <stable@vger.kernel.org> # 3.11+: 3676f9ef: arm64: Move PTE_PROT_NONE higher up
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>