With ARCH_VEXPRESS_SPC option, kernel build has the following
warning:

arch/arm/mach-vexpress/spc.c: In function ‘ve_spc_clk_init’:
arch/arm/mach-vexpress/spc.c:431:38: warning: array subscript is below array bounds [-Warray-bounds]
  struct ve_spc_opp *opps = info->opps[cluster];
                                      ^
since 'cluster' maybe '-1' in UP system. This patch does a active
checking to fix this issue.
Signed-off-by: NAlex Shi <alex.shi@linaro.org>
Acked-by: NPawel Moll <pawel.moll@arm.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

To deal with IPs which are specific to dra74x and dra72x, maintain seperate
ocp interface lists, while keeping the common list for all common IPs.

Move USB OTG SS4 to dra74x only list since its unavailable in
dra72x and is giving an abort during boot. The dra72x only list
is empty for now and a placeholder for future hwmod additions which
are specific to dra72x.

Fixes: d904b38d ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss")
Reported-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
[paul@pwsan.com: fixed comment style to conform with CodingStyle]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Use the corresponding compatibles to identify the devices.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This patch is important for the MicroSOM implementation due to the
following details -

1. VIH of the Atheros phy is 1.7V.
2. NVCC_ENET which is the power domain of the MDIO pad is driven by the
   PHY's LDO (i.e. either 1.8v or 2.5v).
3. The MicroSOM implements an onbouard 1.6kohm pull up to 3.3v (R3000).

In the case the PHY's LDO was 1.8v then there would be only a 100mV
margin for the signal to be acknowledged as high (1.8v-1.7v).
Due to that setting the pad as an open drain will let the 1.6kohm pull
that signal high to 3.3 that assures enough margins to the PHY to be
acked as '1' logic.
Signed-off-by: NRabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>

Similarly to DRA7, OMAP5 has l3 and l4 clock rates incorrectly calculated.
Fixed by using proper divider clock types for the clock nodes.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Reported-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

There were several issues (of varying degree of importance) pointed out
with this code late in the review cycle, yet the code was still merged.
Let's rip it out for now and look at resubmitting at a later time.

This reverts most of commit 4fbe66d9.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Looks like MUSB cable removal can cause wake-up interrupts to
stop working for device tree based booting at least for UART3
even as nothing is dynamically remuxed. This can be fixed by
calling reconfigure_io_chain() for device tree based booting
in hwmod code. Note that we already do that for legacy booting
if the legacy mux is configured.

My guess is that this is related to UART3 and MUSB ULPI
hsusb0_data0 and hsusb0_data1 support for Carkit mode that
somehow affect the configured IO chain for UART3 and require
rearming the wake-up interrupts.

In general, for device tree based booting, pinctrl-single
calls the rearm hook that in turn calls reconfigure_io_chain
so calling reconfigure_io_chain should not be needed from the
hwmod code for other events.

So let's limit the hwmod rearming of iochain only to
HWMOD_FORCE_MSTANDBY where MUSB is currently the only user
of it. If we see other devices needing similar changes we can
add more checks for it.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: stable@vger.kernel.org # v3.16
Signed-off-by: NTony Lindgren <tony@atomide.com>

For device tree based booting, we need to use wake-up
interrupts like we already do for some omaps. This fixes
a PM regression on beagleboard compared to legacy booting.
Tested-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The kernel has never supported clk32g as a regulator since it is a clock
and not a regulator. Fortunately nothing actually references this node so
we can just remove it.
Signed-off-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

When an alias for a clock already exists the warning is printed. For
every module with a main_clk defined, a clk alias for fck is added.
There are some components that have the same main_clk defined, so this
is a really normal situation.

For example the am33xx edma device has 4 components using the same main
clock. So there are three warnings in the boot log for this already
existing clock alias:
	platform 49000000.edma: alias fck already exists
	platform 49000000.edma: alias fck already exists
	platform 49000000.edma: alias fck already exists

As this is only interesting for developers, this patch changes the
message to a debug message.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix %d confusingly prefixed with 0x in format string.
Signed-off-by: NHans Wennborg <hans@hanshq.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

GPIO modules are also interrupt sources. However, they require both the
GPIO number and IRQ type to function properly.

By declaring that GPIO uses interrupt-cells=<1>, we essentially do not
allow users of the nodes to use the interrupt property appropritely.

With this change, the following now works:

interrupt-parent = <&gpio6>;
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;

Fixes: 6e58b8f1 ('ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board')
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For v3.14 and prior, 1-bit Hamming code ECC via software was used
for NAND on this board.
Commit c06c5270 in v3.15 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.14
and prior to be unusable in v3.15 and later. So revert back to
using software ECC scheme.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For v3.14 and prior, 1-bit Hamming code ECC via software was the
default choice for some boards e.g. 3430sdp.
Commit ac65caf5 in v3.15 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.14
and prior to be unusable in v3.15 and later. So don't mark "sw" scheme
as deperecated and support it.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For v3.12 and prior, 1-bit Hamming code ECC via software was the
default choice. Commit c66d0391 in v3.13 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.12
and prior to be unusable in v3.13 and later. So revert back to
using software ECC by default if an ECC scheme is not explicitely
specified.

This defect can be observed on the following boards during legacy boot

-omap3beagle
-omap3touchbook
-overo
-am3517crane
-devkit8000
-ldp
-3430sdp
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>

Hummingboard has no over current hardware, so disable the over current
detection for both ports.

Cubox-i has over current hardware, so appropriately configure this.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>

On r8a7791, i2c6 (aka iic3) doesn't need pinmux, but the koelsch dts
refers to non-existent pinmux configuration data:

pinmux core: sh-pfc does not support function i2c6
sh-pfc e6060000.pfc: invalid function i2c6 in map table

Remove it to fix this.

Fixes: commit 1d41f36a ("ARM: shmobile:
       koelsch dts: Add VDD MPU regulator for DVFS")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Working on Gigabit/PCIe support in U-Boot for Apalis T30 I realised
that the current device tree source includes for our modules only
happen to work due to referencing the on-carrier 5v0 supply from USB
which is not at all available on-module. The modules actually contain
TPS60150 charge pumps to generate the PMIC required 5 volts from the
one and only 3.3 volt module supply. This patch fixes this.

(Note: When back-porting this to v3.16 stable releases, simply drop the
change to tegra30-apalis.dtsi; that file was added in v3.17)

Cc: <stable@vger.kernel.org> #v3.16+
Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

During the restructuring of the Rockchip Cortex-A9 dtsi files it seems
like the pinctrl settings vanished at some point from the mmc0 support.

This of course renders them unusable, so readd the necessary pinctrl
properties.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

"efi" global data structure contains "runtime_version" field which must
be assigned in order to use it later in Runtime Services virtual calls
(virt_efi_* functions).

Before this patch "runtime_version" was unassigned (0), so each
Runtime Service virtual call that checks revision would fail.
Signed-off-by: NSemen Protsenko <semen.protsenko@linaro.org>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>

Currently the sh-intc driver is compiled on all SuperH and
non-multiplatform SH-Mobile platforms, while it's only used on a limited
number of platforms:
  - SuperH: SH2(A), SH3(A), SH4(A)(L) (all but SH5)
  - ARM: sh7372, sh73a0

Drop the "default y" on SH_INTC, make all CPU platforms that use it
select it, and protect all sub-options by "if SH_INTC" to fix this.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NMagnus Damm <damm+renesas@opensource.se>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

4bfb358b
(ARM: shmobile: Add r8a7791 legacy SDHI clocks)
added r8a7791 SDHI clock support.

But, it is missing
"0x0100: x 1/8" division ratio.
This patch fixes hidden bug.
It is based on R-Car H2 v0.7, R-Car M2 v0.9.
Reported-by: NYusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

9f13ee6f
(ARM: shmobile: r8a7790: add div4 clocks)
added r8a7790 DIV4 clock support.

But, it is missing
"0x0100: x 1/8" division ratio.
This patch fixes hidden bug.
It is based on R-Car H2 v0.7, R-Car M2 v0.9.
Reported-by: NYusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Add new memfd_create syscall.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Add new getrandom syscall.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Add new seccomp syscall.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Increase max i2c bus frequency beyond the default for faster
data transfers. According to the manual, these faster speeds are
only available when the board is wired up the right way. In this case,
the vendor kernel has run at this speed for a long time.

sda-delay is needed for talking to RTC on PMIC, otherwise the i2c
controller never sees an ACK. Strangely the other PMIC i2c slave (the
main one) works fine even without this delay. I Chose value 100 to
match the vendor kernel.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The ODROID kernel shows that the PMIC interrupt line is hooked up
to pin GPX3-2.

This is needed for the max77686-irq driver to create the PMIC IRQ
domain, which is needed by max77686-rtc.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Tested-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

For some reason, the audit patches didn't make it out of -next this
merge window, so revert our temporary hack and let the audit guys deal
with fixing up -next.

This reverts commit 2a8f45b0.
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Now that we support 48-bit physical addressing, update MAX_PHYSMEM_BITS
accordingly.
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NGanapatrao Kulkarni <ganapatrao.kulkarni@caviumnetworks.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

UEFI provides its own method for marking regions to reserve, via the
memory map which is also used to initialise memblock. So when using the
UEFI memory map, ignore any memreserve entries present in the DT.
Reported-by: NMark Rutland <mark.rutland@arm.com>
Reviewed-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Currently when run on an APM platform the ARMv8 defconfig has no viable
options for rootfs other than ramdisk which is rather limiting. Since
we already have both SATA and the bits needed for NFS root enabled we just
need to enable the relevant drivers so do that, helping enable direct
testing of upstream.

If the configuration ends up becoming too big we can consider modularising
some of the drivers and asking people to use an initramfs but for now this
is not an issue.
Signed-off-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

When booting via UEFI, the kernel Image is loaded at a 4 kB boundary and
the embedded EFI stub is executed in place. The EFI stub relocates the
Image to reside TEXT_OFFSET bytes above a 2 MB boundary, and jumps into
the kernel proper.

In AArch64, PC relative symbol references are emitted using adrp/add or
adrp/ldr pairs, where the offset into a 4 kB page is resolved using a
separate :lo12: relocation. This implicitly assumes that the code will
always be executed at the same relative offset with respect to a 4 kB
boundary, or the references will point to the wrong address.

This means we should link the kernel at a 4 kB aligned base address in
order to remain compatible with the base address the UEFI loader uses
when doing the initial load of Image. So update the code that generates
TEXT_OFFSET to choose a multiple of 4 kB.

At the same time, update the code so it chooses from the interval [0..2MB)
as the author originally intended.
Reviewed-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

get_system_type() is not thread-safe on OCTEON. It uses static data,
also more dangerous issue is that it's calling cvmx_fuse_read_byte()
every time without any synchronization. Currently it's possible to get
processes stuck looping forever in kernel simply by launching multiple
readers of /proc/cpuinfo:

	(while true; do cat /proc/cpuinfo > /dev/null; done) &
	(while true; do cat /proc/cpuinfo > /dev/null; done) &
	...

Fix by initializing the system type string only once during the early
boot.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nsn.com>
Cc: stable@vger.kernel.org
Reviewed-by: NMarkos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7437/Signed-off-by: NJames Hogan <james.hogan@imgtec.com>

The CPS code is doing several memory loads when configuring the VPEs
from secondary cores, so the segmentation control registers must be
initialized in time otherwise the kernel will crash with strange
TLB exceptions.
Reviewed-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7424/Signed-off-by: NJames Hogan <james.hogan@imgtec.com>

Rename 'eva_entry' to 'platform_eva_init' as required by the new
'eva_init' macro in the eva.h header. Since this macro is now used
in a platform dependent way, it must not depend on its caller so move
the t1 register initialization inside this macro. Also set the .reorder
assembler option in case the caller may have previously set .noreorder.
This may allow a few assembler optimizations. Finally include missing
headers and document the register usage for this macro.
Reviewed-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7423/Signed-off-by: NJames Hogan <james.hogan@imgtec.com>

Generic code may need to perform certain operations when EVA is
enabled, for example, configure the segmentation registers during
boot. In order to avoid using more CONFIG_EVA ifdefs in the arch code,
such functions will be added in this header instead.
Initially this header contains a macro which will be used by generic
code later on during VPEs configuration on secondary cores.
All it does is to call the platform specific EVA init code in case
EVA is enabled.
Reviewed-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7422/Signed-off-by: NJames Hogan <james.hogan@imgtec.com>

Commit 4c21b8fd (MIPS: seccomp: Handle indirect system calls (o32))
added indirect syscall detection for O32 processes running on MIPS64
but it did not work as expected. The reason is the the scall64-o32
implementation differs compared to scall32-o32. In the former, the v0
(syscall number) register contains the absolute syscall number
(4000 + X) whereas in the latter it contains the relative syscall
number (X). Fix the code to avoid doing an extra addition, and load
the v0 register directly to the first argument for syscall_trace_enter.
Moreover, set the .reorder assembler option in order to have better
control on this part of the assembly code.
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7481/
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>

On MIPS64, O32 processes set both TIF_32BIT_ADDR and
TIF_32BIT_REGS so the previous condition treated O32 applications
as N32 when evaluating seccomp filters. Fix the condition to check
both TIF_32BIT_{REGS, ADDR} for the N32 AUDIT flag.
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7480/
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>