The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn
instructions (where the optional alignment hint is given but incorrect)
as LDR/STR, leading to register corruption. Detect these and correctly
treat them as unhandled, so that userspace gets the fault it expects.
Reported-by: Simon Hosie <simon.hosie@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
SCTLR.HA (hardware access flag) is deprecated and not actually
implemented by any CPUs. Furthermore, it can confuse cr_alignment checks
where the whole value of SCTLR is compared against the value sitting in
the hardware, since the bit is actually RAZ/WI and will not match the
saved cr_alignment value.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rob Clark reports a sleeping while atomic bug when using perf.
BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:583
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
------------[ cut here ]------------
WARNING: CPU: 2 PID: 4828 at ../kernel/locking/mutex.c:479 mutex_lock_nested+0x3a0/0x3e8()
DEBUG_LOCKS_WARN_ON(in_interrupt())
Modules linked in:
CPU: 2 PID: 4828 Comm: Xorg.bin Tainted: G W 3.17.0-rc3-00234-gd535c45-dirty #819
[<c0216690>] (unwind_backtrace) from [<c0212174>] (show_stack+0x10/0x14)
[<c0212174>] (show_stack) from [<c0867cc0>] (dump_stack+0x98/0xb8)
[<c0867cc0>] (dump_stack) from [<c02492a4>] (warn_slowpath_common+0x70/0x8c)
[<c02492a4>] (warn_slowpath_common) from [<c02492f0>] (warn_slowpath_fmt+0x30/0x40)
[<c02492f0>] (warn_slowpath_fmt) from [<c086a3f8>] (mutex_lock_nested+0x3a0/0x3e8)
[<c086a3f8>] (mutex_lock_nested) from [<c0294d08>] (irq_find_host+0x20/0x9c)
[<c0294d08>] (irq_find_host) from [<c0769d50>] (of_irq_get+0x28/0x48)
[<c0769d50>] (of_irq_get) from [<c057d104>] (platform_get_irq+0x1c/0x8c)
[<c057d104>] (platform_get_irq) from [<c021a06c>] (cpu_pmu_enable_percpu_irq+0x14/0x38)
[<c021a06c>] (cpu_pmu_enable_percpu_irq) from [<c02b1634>] (flush_smp_call_function_queue+0x88/0x178)
[<c02b1634>] (flush_smp_call_function_queue) from [<c0214dc0>] (handle_IPI+0x88/0x160)
[<c0214dc0>] (handle_IPI) from [<c0208930>] (gic_handle_irq+0x64/0x68)
[<c0208930>] (gic_handle_irq) from [<c0212d04>] (__irq_svc+0x44/0x5c)
Exception stack(0xe63ddea0 to 0xe63ddee8)
dea0: 00000001 00000001 00000000 c2f3b200 c16db380 c032d4a0 e63ddf40 60010013
dec0: 00000000 001fbfd4 00000100 00000000 00000001 e63ddee8 c0284770 c02a2e30
dee0: 20010013 ffffffff
[<c0212d04>] (__irq_svc) from [<c02a2e30>] (ktime_get_ts64+0x1c8/0x200)
[<c02a2e30>] (ktime_get_ts64) from [<c032d4a0>] (poll_select_set_timeout+0x60/0xa8)
[<c032d4a0>] (poll_select_set_timeout) from [<c032df64>] (SyS_select+0xa8/0x118)
[<c032df64>] (SyS_select) from [<c020e8e0>] (ret_fast_syscall+0x0/0x48)
---[ end trace 0bb583b46342da6f ]---
INFO: lockdep is turned off.
We don't really need to get the platform irq again when we're
enabling or disabling the per-cpu irq. Furthermore, we don't
really need to set and clear bits in the active_irqs bitmask
because that's only used in the non-percpu irq case to figure out
when the last CPU PMU has been disabled. Just pass the irq
directly to the enable/disable functions to clean all this up.
This should be slightly more efficient and also fix the
scheduling while atomic bug.
Fixes: bbd6455937 "ARM: perf: support percpu irqs for the CPU PMU"
Reported-by: Rob Clark <robdclark@gmail.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The TPIDRURO and TPIDRURW registers need to be flushed during exec;
otherwise TLS information is potentially leaked. TPIDRURO in
particular needs careful treatment. Since flush_thread basically
needs the same code used to set the TLS in arm_syscall, pull that into
a common set_tls helper in tls.h and use it in both places.
Similarly, TEEHBR needs to be cleared during exec as well. Clearing
its save slot in thread_info isn't right as there is no guarantee
that a thread switch will occur before the new program runs. Just
setting the register directly is sufficient.
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Previous commits that dealt with get_user for 64bit type missed to
export proper functions, so if get_user macro with particular target/value
types are used by kernel module modpost would produce 'undefined!' error.
Solution is to export all required functions.
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
e38361d 'ARM: 8091/2: add get_user() support for 8 byte types' commit
broke V7 BE get_user call when target var size is 64 bit, but '*ptr' size
is 32 bit or smaller. e38361d changed type of __r2 from 'register
unsigned long' to 'register typeof(x) __r2 asm("r2")' i.e before the change
even when target variable size was 64 bit, __r2 was still 32 bit.
But after e38361d commit, for target var of 64 bit size, __r2 became 64
bit and now it should occupy 2 registers r2, and r3. The issue in BE case
that r3 register is least significant word of __r2 and r2 register is most
significant word of __r2. But __get_user_4 still copies result into r2 (most
significant word of __r2). Subsequent code copies from __r2 into x, but
for situation described it will pick up only garbage from r3 register.
Special __get_user_64t_(124) functions are introduced. They are similar to
corresponding __get_user_(124) function but result stored in r3 register
(lsw in case of 64 bit __r2 in BE image). Those function are used by
get_user macro in case of BE and target var size is 64bit.
Also changed __get_user_lo8 name into __get_user_32t_8 to get consistent
naming accross all cases.
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Suggested-by: Daniel Thompson <daniel.thompson@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
According to the ARM ARMv7, explicit barriers are necessary when using
synchronisation primitives such as SWP{B}. The use of these
instructions does not automatically imply a barrier and any ordering
requirements by the software must be explicitly expressed with the use
of suitable barriers.
Based on this, remove the barriers from SWP{B} emulation.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since commit 1dbfa187da ("ARM: irq migration: force migration off CPU
going down") the ARM interrupt migration code on cpu offline calls
irqchip.irq_set_affinity() with the argument force=true. At the point
of this change the argument had no effect because it was not used by
any interrupt chip driver and there was no semantics defined.
This changed with commit 01f8fa4f01 ("genirq: Allow forcing cpu
affinity of interrupts") which made the force argument useful to route
interrupts to not yet online cpus without checking the target cpu
against the cpu online mask. The following commit ffde1de640
("irqchip: gic: Support forced affinity setting") implemented this for
the GIC interrupt controller.
As a consequence the ARM cpu offline irq migration fails if CPU0 is
offlined, because CPU0 is still set in the affinity mask and the
validataion against cpu online mask is skipped to the force argument
being true. The following first_cpu(mask) selection always selects
CPU0 as the target.
Solve the issue by calling irq_set_affinity() with force=false from
the CPU offline irq migration code so the GIC driver validates the
affinity mask against CPU online mask and therefore removes CPU0 from
the possible target candidates.
Tested on TC2 hotpluging CPU0 in and out. Without this patch the system
locks up as the IRQs are not migrated away from CPU0.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # 3.10.x
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: LPAE: drop wrong carry flag correction after adding TTBR1_OFFSET
In commit 7fb00c2fca ("ARM: 8114/1: LPAE:
load upper bits of early TTBR0/TTBR1") part which fixes carrying in adding
TTBR1_OFFSET to TTRR1 was wrong:
addls ttbr1, ttbr1, #TTBR1_OFFSET
adcls tmp, tmp, #0
addls doesn't update flags, adcls adds carry from cmp above:
cmp ttbr1, tmp @ PHYS_OFFSET > PAGE_OFFSET?
Condition 'ls' means carry flag is clear or zero flag is set, thus only one
case is affected: when PHYS_OFFSET == PAGE_OFFSET.
It seems safer to remove this fixup. Bug is here for ages and nobody
complained. Let's fix it separately.
Reported-and-Tested-by: Jassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit af040ffc9b ("ARM: make it easier to check the CPU part number
correctly") changed ARM_CPU_PART_X masks, and the way they are returned and
checked against. Usage of read_cpuid_part_number() is now deprecated, and
calling places updated accordingly. This actually broke cpuidle-big_little
initialization, as bl_idle_driver_init() performs a check using an hardcoded
mask on cpu_id.
Create an interface to perform the check (that is now even easier to read).
Define also a proper mask (ARM_CPU_PART_MASK) that makes this kind of checks
cleaner and helps preventing bugs in the future. Update usage accordingly.
Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may
falsely trigger a watchpoint exception, leading to potential data aborts
during exception return and/or livelock.
This patch resolves the issue in the following ways:
- Replacing our uses of CLREX with a dummy STREX sequence instead (as
we did for v6 CPUs).
- Removing the clrex code from v7_exit_coherency_flush and derivatives,
since this only exists as a minor performance improvement when
non-cached exclusives are in use (Linux doesn't use these).
Benchmarking on a variety of ARM cores revealed no measurable
performance difference with this change applied, so the change is
performed unconditionally and no new Kconfig entry is added.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors
upon entry to the kernel, but this is redundant:
- We clear the monitors on every exception return since commit
200b812d00 ("Clear the exclusive monitor when returning from an
exception"), so this is not necessary to ensure the monitors are
cleared before returning from a fault handler.
- Any dummy STREX will target a temporary scratch area in memory, and
may succeed or fail without corrupting useful data. Its status value
will not be used.
- Any other STREX in the kernel must be preceded by an LDREX, which
will initialise the monitors consistently and will not depend on the
earlier state of the monitors.
Therefore we have no reason to care about the initial state of the
exclusive monitors when a data abort is taken, and clearing the monitors
prior to exception return (as we already do) is sufficient.
This patch removes the redundant clearing of the exclusive monitors from
the early abort handlers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Kernel module build with GCOV profiling fails to load with the
following error:
$ insmod test_module.ko
test_module: unknown relocation: 38
insmod: can't insert 'test_module.ko': invalid module format
This happens because constructor pointers in the .init_array section
have not supported R_ARM_TARGET1 relocation type.
Documentation (ELF for the ARM Architecture) says:
"The relocation must be processed either in the same way as R_ARM_REL32 or
as R_ARM_ABS32: a virtual platform must specify which method is used."
Since kernel expects to see absolute addresses in .init_array R_ARM_TARGET1
relocation type should be treated the same way as R_ARM_ABS32.
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Confine SH_INTC to platforms that need it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJT+oswAAoJENfPZGlqN0++/A8QAK2yp96zl7gABtddgkunNJiV
xWCm4wcP+7dIrLpwizxtt/6HMPj9ZJHYtcxRRKVlzquwcukeVCIkfZ3Qvn2JilWM
+b4rVRGzQ+z0M7SCpNGjtgFc1IFrVrzuxZpPwgseQ5I6HQsZJKUi3qn5rRJSEax2
w+ANis2eZfmSBdu3Qsx2QBDXvS7ZPlLpimoAE+rjr60dZnljcrvBrVHQvSgpEHxn
4rXPbYrrkIee32J4lxLRDPtn5fvAsrr+vcLXEYqyFr2292U2PAxIrjZgrRzZYNtD
L6xmhZAhdmIpC0gLDLyKQhwj/9pfGFxFErZX9jeGdPT2KTEEYPkSxb75kdTwmxP4
DEtZG9Nuu6CQCBldrMt6kpujn+XCYRl94cSyUffJ5KVhNUiqB+e+JP80Yj9HB7QU
nGUfs2hQ/azY8XEiwvnls0314thkB5gN7KHxmlaFa9Wz7cgYFwWAguHH8qrq839U
+i+7dUg7nlmVoIAvzYIIA+L7x3xX4gEwsf88x3i04DPp0A8/oDAwGrqM5QzsaZpD
ghodnKRG7foc+29RLYka5CxF/MqKzpJu675sSBCVB3uW9NZpoGSwml/NN9yUu1JD
uvU2FECcbxF5OU6RHfq8FFql0fAOVeVWsMCEXgkjpZOXynKU15VTf1K2d+qkUZ/Y
gV45Jj+yCZhYs0wbXUml
=QSyy
-----END PGP SIGNATURE-----
Merge tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas
Pull SH driver fix from Simon Horman:
"Confine SH_INTC to platforms that need it"
* tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
sh: intc: Confine SH_INTC to platforms that need it
Pull MIPS fixes from Ralf Baechle:
"Pretty much all across the field so with this we should be in
reasonable shape for the upcoming -rc2"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: OCTEON: make get_system_type() thread-safe
MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores
MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_init'
MIPS: EVA: Add new EVA header
MIPS: scall64-o32: Fix indirect syscall detection
MIPS: syscall: Fix AUDIT value for O32 processes on MIPS64
MIPS: Loongson: Fix COP2 usage for preemptible kernel
MIPS: NL: Fix nlm_xlp_defconfig build error
MIPS: Remove race window in page fault handling
MIPS: Malta: Improve system memory detection for '{e, }memsize' >= 2G
MIPS: Alchemy: Fix db1200 PSC clock enablement
MIPS: BCM47XX: Fix reboot problem on BCM4705/BCM4785
MIPS: Remove duplicated include from numa.c
MIPS: Add common plat_irq_dispatch declaration
MIPS: MSP71xx: remove unused plat_irq_dispatch() argument
MIPS: GIC: Remove useless parens from GICBIS().
MIPS: perf: Mark pmu interupt IRQF_NO_THREAD
Pull x86 fixes from Ingo Molnar:
"A couple of EFI fixes, plus misc fixes all around the map"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/arm64: Store Runtime Services revision
firmware: Do not use WARN_ON(!spin_is_locked())
x86_32, entry: Clean up sysenter_badsys declaration
x86/doc: Fix the 'tlb_single_page_flush_ceiling' sysconfig path
x86/mm: Fix sparse 'tlb_single_page_flush_ceiling' warning and make the variable read-mostly
x86/mm: Fix RCU splat from new TLB tracepoints
A collection of fixes from this week, it's been pretty quiet and nothing
really stands out as particularly noteworthy here -- mostly minor fixes
across the field:
- ODROID booting was fixed due to PMIC interrupts missing in DT
- A collection of i.MX fixes
- Minor Tegra fix for regulators
- Rockchip fix and addition of SoC-specific mailing list to make it
easier to find posted patches.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJT+jEaAAoJEIwa5zzehBx3gPIP/2EMvkRiFL73z6u67d6AhqCR
UPpv65Lk0FzvKZYvpNdNDdPatS48SpEh4Ppj58HegK31jaZIYhsvGHFsAwrHpZXF
2D2H8Vqy6wl+UL+BQGTHJ2rhqgg40PSZQh1KksaBrjb9MDWUbAI0V9AysoT6ecIP
/02mzRkNPL7V5ISikksa82FWbZwI36KJGTM19ZDp6CYQnV2L4eG0LefGjgEzdE07
iur1PO/TUi0ibQex3It9D+ynNlza0sZJDR0AsGFTS/96fvtX6SQzvxtEsr4jUfyT
jceqD5KIWS9N1OmRudJ+e3awpzGGuRIkdq36eiJbhSe426LHgDNbIS4RU+YRNFIf
9/bK4blcxGNnddsDTLUIyi+vykAm1ObAfGNNrKeA4z9lDw0QVuoG5VwrgNKcIk3J
kugj3RLUQ5yd9iIFJyrPxlpB5mTo5SaPCSxjuDKzftwDQtF+SJI58V//Nde0Ocfw
K7VpmY26uYUmf6AltiyFxOCUASzUC3Bp+/cf0lYTWE1+iIuOTJRlYmYwKDMrJ+c0
mtz3uCiQhTzaHje6AksA1wlKhv3KS/opGN1oNVSILgjExiRGh94MSkROLqtJ35cE
WV/nuzZUPdmZ6tGQ6b7FEa0elbEElaioDiQraOeSehKijEjfhK+tHNJczoO94s2R
Swfff4NwRe346ZMk/L/2
=+oYu
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A collection of fixes from this week, it's been pretty quiet and
nothing really stands out as particularly noteworthy here -- mostly
minor fixes across the field:
- ODROID booting was fixed due to PMIC interrupts missing in DT
- a collection of i.MX fixes
- minor Tegra fix for regulators
- Rockchip fix and addition of SoC-specific mailing list to make it
easier to find posted patches"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
bus: arm-ccn: Fix warning message
ARM: shmobile: koelsch: Remove non-existent i2c6 pinmux
ARM: tegra: apalis/colibri t30: fix on-module 5v0 supplies
MAINTAINERS: add new Rockchip SoC list
ARM: dts: rockchip: readd missing mmc0 pinctrl settings
ARM: dts: ODROID i2c improvements
ARM: dts: Enable PMIC interrupts on ODROID
ARM: dts: imx6sx: fix the pad setting for uart CTS_B
ARM: dts: i.MX53: fix apparent bug in VPU clks
ARM: imx: correct gpu2d_axi and gpu3d_axi clock setting
ARM: dts: imx6: edmqmx6: change enet reset pin
ARM: dts: vf610-twr: Fix pinctrl_esdhc1 pin definitions.
ARM: imx: remove unnecessary ARCH_HAS_OPP select
ARM: imx: fix TLB missing of IOMUXC base address during suspend
ARM: imx6: fix SMP compilation again
ARM: dt: sun6i: Add #address-cells and #size-cells to i2c controller nodes
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 1d41f36a68 ("ARM: shmobile:
koelsch dts: Add VDD MPU regulator for DVFS")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Olof 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: Marcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
dts files and addition of the new Rockchip list to MAINTAINERS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCAAGBQJT+hwkAAoJEPOmecmc0R2Bda4IAJ7rxypWxi8RtfxULHu1oGxZ
cdmAsaedAkjTn6tye/99lv1WkLzUD+Q3AxLX6Glu8PgTkocbwtkVTP+gMbv7zwfN
Z9bA6kazPL4Rskr6Am8BFKkGhXHCXChGP1J3z9Gyh07Vu2+3zsvRzyM7hySt3TqZ
EA2dL/uODlukw6EPzFaqGWZLn1OuJmkHXDfnZ3lBI/GFZD9qt5DnYswMBlDlIwr6
D08jmcleRA3wpnY1HXYR2cN1sJmcEP6xVE8ApXd71X0MtumEy49ZTR+4T5/Sh/XN
OPheoH3UUVtXVrAa5fsoUE2xsKs3PZgnIHk1kQklpbw+HArbN+aW0Jh6CySb65Q=
=aNJj
-----END PGP SIGNATURE-----
Merge tag 'v3.17-rockchip-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes
Merge "ARM: rockchip: fix for 3.17" from Heiko Stubner:
Pinctrl that got accidentially dropped when reorganizing the
dts files and addition of the new Rockchip list to MAINTAINERS.
* tag 'v3.17-rockchip-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
MAINTAINERS: add new Rockchip SoC list
ARM: dts: rockchip: readd missing mmc0 pinctrl settings
Signed-off-by: Olof 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: Heiko Stuebner <heiko@sntech.de>
Only a single patch in here that fixes a DTC warning.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJT2hD6AAoJEBx+YmzsjxAgV9YP/1wML2m04CODnLmLhKyx1GyM
VyBoEHb+o7P7TRyK7ePIVkGhGnQjYGMyXAI2KfOiBJpAl23uxXCXSNKc6WY+nBAw
6T6qL6w+tPIPW4B79fAjmoPksqhoVf9sAKAkdu6+ETwKMHRaF0IesPRTg9t21Wcd
yHHDY4z/qaFCMV59zeOIWMxM0V0gvUa46+bXC2flyTcTz5RgyUswCOXKHLvXfK1L
w8B+V34AeBtm2EzG6co1iOJVRKXlrjzUg25+adbRissNfvmVkPwYkQJNoBO6r/PO
Rxf7Mq50oovPl/Oc83e3RZl3tE8ds12t+ScS0qUFq6+tBvyq53IYP+51IhDOGiR3
a6PB1nPEXtvUt09xv5SPJiRsB+BFrh5hx+qWbDvUNQL5FZrqBxa63H6qArybFQXg
GaY8Zv5gdiMvAU0tdk7v4pduJkvvoG2GALGHPrcKmrpg2+qQ4LDKOJxErIEqOUi2
ERp7c0kODDz18F9OmjGYU2R7XT6Ji8h4MS/hbCiLajcboQMe3yClrcVB8ts+AUKJ
NSDWl5Q0/8uHhk40FAaGYEqVLakk8vhXwdg1hpcXzIg3dJg+P09dYK5nIOBzKIok
+eVXZ8xjcRnoBAumljZ3eGbTuysGDO95E56coDPE4IiAe4Esi7kl3fUS/NICoOGs
MC9tjeyMoscy+hoGsP57
=PL45
-----END PGP SIGNATURE-----
Merge tag 'sunxi-dt-for-3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
Merge "Allwinner DT changes, take 2" from Maxime Ripard:
Only a single patch in here that fixes a DTC warning.
* tag 'sunxi-dt-for-3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
ARM: dt: sun6i: Add #address-cells and #size-cells to i2c controller nodes
Signed-off-by: Olof Johansson <olof@lixom.net>
This small set of fixes addresses a few issues introduced during the
merge window, including:
- Fix typo in I-cache detection that was causing us to treat all
I-caches as aliasing
- Hook up memfd_create and getrandom syscalls for native and compat
- Revert a temporary hack for defconfig builds in -next (the audit
tree changes didn't make it in this merge window)
- A couple of UEFI fixes for TEXT_OFFSET fuzzing and /memreserve/
- A simple sparsemem fix for 48-bit physical addressing
- Small defconfig updates to get autotesters working with X-gene
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCgAGBQJT9j4lAAoJEC379FI+VC/ZjVAP/jxBpU5V8i4aUiVVbG4efcTL
elpu74kPek4LgyI55YZPdxo6Hc5BX/STC06hq6s//vFwSNf0tS+12sOCMpjHkhfU
oRkuQR4TDgTAo4BvrONHYbwSyQclWS+VhKXp4NwTTIwmA5Mg9jgRQCp+VHGTPzZC
UK3nObqVVVZh6BHzjEIMfy25mkChULdm8A6IG8ciNSrHxKVNMTAJTE1eKE/92ccM
cs18zlymRPl02amf/tUgTFxHBgRoFZcaFpM7Qge3AUZY95U70kpEiPGLQNfJ2UBH
NfcWr9LkdMGXULYdfO98akn7boIFW7W+BuHASCfp+di4odcQDjYQvDAvg1NZ3OCi
C3IyISYyxBjP9kgShXrIAeDtDP9vjy6aj/E/rhq3ByNSewdP+f9roVq1oapuNs9F
lAerIiqC8+LMLBan0EOuyaj3MOEGUh26qOUaKY8HEmlDXDJD5ceGsB3dROAx2mtV
FhU7kqp717ETCloxtmJuZUrIlL+e3SZznnT4aCduL3/S9Jd5wdBTCUdqEoGnwBy/
rkSjaP9D4QbBP3vMPaK7ANv2aRpjo3U2AuBsqL7iSjdKjj+IqQfNn5qIsTFNfVup
zOUcecVSdntZj19ejbUj7+TGxEV+9er+HPEtqKo7Pii6zl+Mf8HsqsScAq1FZbw/
2r/W9FODi0gN4WgKnNb1
=BqdY
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"This small set of fixes addresses a few issues introduced during the
merge window, including:
- fix typo in I-cache detection that was causing us to treat all
I-caches as aliasing
- hook up memfd_create and getrandom syscalls for native and compat
- revert a temporary hack for defconfig builds in -next (the audit
tree changes didn't make it in this merge window)
- a couple of UEFI fixes for TEXT_OFFSET fuzzing and /memreserve/
- a simple sparsemem fix for 48-bit physical addressing
- small defconfig updates to get autotesters working with X-gene"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
Revert "arm64: Do not invoke audit_syscall_* functions if !CONFIG_AUDIT_SYSCALL"
arm64: mm: update max pa bits to 48
arm64: ignore DT memreserve entries when booting in UEFI mode
arm64: configs: Enable X-Gene SATA and ethernet in defconfig
arm64: align randomized TEXT_OFFSET on 4 kB boundary
asm-generic: add memfd_create system call to unistd.h
arm64: compat: wire up memfd_create and getrandom syscalls for aarch32
arm64: fix typo in I-cache policy detection
Swap it for the more canonical lockdep_assert_held() which always
does the right thing - Guenter Roeck
* Assign the correct value to efi.runtime_version on arm64 so that all
the runtime services can be invoked - Semen Protsenko
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJT9vVeAAoJEC84WcCNIz1V3EsP/0iwFVj8zwIzivI4Oot1hyHv
JTKbjANPu82FqnLFoVjssbFY2wlO2SY73baOhPdRJ/978M64dDpWH+wutgBKh6b8
OA5kTv+gD1QxIpiLIcy9GnO1at9O7H8J/FGEAaQHvLRdA5tCwRpLoVObqQM1QTnN
tLn0Q2RsjlIVYBwgLZHgq7WEOUUt53OlXScPdOENaw8wBacgJOAdH6FeRFUmIauO
uXHuZfVYG6pDqsOYgMYTuBNpyUBDL1Gvowtd3CMcjDFd6RDyYYE00s0YoNI2QfWP
3xBah4hZ6wUnG/duvlsaxeABX+wxTGYRZaJ3ts80MCEz6xIoN2dAueWHevJtp9sB
8S6xgsmlt+K/T3aa47xOsykBb025bnh5F1wFW6Klsd/Jm4YIRGCZf//n7/7jNQP/
cC6Ka9atn+urxP8rFGOGMemhiBg7p61oo0WsrDxIvsh7X0aGwiNMgpniyqr4ZrrE
WGJUxfyMVFJu31DJjfKKqPkuOAPVCPSs8GiecY9mgLha3Q8alVqmr4JzlXOy9rP/
Q7rIsCRueb6rRaAA0OWyVK/ahZ9ahvY5K71XxcmpS5e5jNhwfxoMlqh4CDrEYRmC
tvGnj4I4SYn7iCjYxyk84l+igoguWp5LIq8pZeT5WjZztEG7ZBP4ciQFFBVWCeen
S2+vRUBkBn7y5HrTfiUs
=IUiu
-----END PGP SIGNATURE-----
Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent
Pull EFI fixes from Matt Fleming:
* WARN_ON(!spin_is_locked()) always triggers on non-SMP machines.
Swap it for the more canonical lockdep_assert_held() which always
does the right thing - Guenter Roeck
* Assign the correct value to efi.runtime_version on arm64 so that all
the runtime services can be invoked - Semen Protsenko
Signed-off-by: Ingo Molnar <mingo@kernel.org>
"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: Semen Protsenko <semen.protsenko@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt 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: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
(one has a CVE), and fixing some problems introduced during the merge window
(the CMA bug came in via Andrew, the x86 ones via yours truly).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJT9IfLAAoJEBvWZb6bTYbyAG8P/2GLPast76I9Pc269UNACV0f
vNgJfSAH97PrEQtVzCurqb0RKHMKcZ5XyYmKh5TvzlbWYXnqJuJr5TrIh0gsuxn9
DaBKVgeXBTd43OCRXJKw6SgkKlnf+yfQeASLRwjQgVCqsvNR/rKksEPjAhVqQJIJ
PlRYKeBc7SA8bPUG64GDtF3yP9e/KG5ItGudj4eUADtadPmyldJbTWl0zLwY7jvJ
/qcSxRgwqUsIS0c8xE5rlByxuWQ43RF+MfohNttNUjXD/dhvJo07NpkPUS6TsqHf
x1VyWPuIY1zB/WghKutI8oZxS14iUs1l0LL9egS7fc4sYQqQ7+HHLaJnEMloTXqF
GYfwmnyz53ocR1M4dgCPyBi0uxM3ydRzbSnsToR2kzVdS3WKu5O8GfjkE2zooEaA
OP77OsSxtl5mLD68ZtubmLt8ttYCiWOEIOzviUSoJjPv0gUE07oAjecp7C8nKDCP
lUxM2JZ01SLSzRf3uSlrNfRpeyMWVmYhyiG3lqLmph9FfP7p4donbIdh/QA0W7Nj
E2GEEv3lCUZp7+TnOydsiWNVwv026dDanh5QLSuCvfCqf+xhNMJbrRzlbUpfGAsm
89XasETdOnAqIO9VOOBLAKE2wrMEx+9vT2G0Dv3e+3IedGwLuM7/53X4zXUIB8ys
L9C7kZwci9+X3qIExWJI
=lhLd
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"Reverting a 3.16 patch, fixing two bugs in device assignment (one has
a CVE), and fixing some problems introduced during the merge window
(the CMA bug came in via Andrew, the x86 ones via yours truly)"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
virt/kvm/assigned-dev.c: Set 'dev->irq_source_id' to '-1' after free it
Revert "KVM: x86: Increase the number of fixed MTRR regs to 10"
KVM: x86: do not check CS.DPL against RPL during task switch
KVM: x86: Avoid emulating instructions on #UD mistakenly
PC, KVM, CMA: Fix regression caused by wrong get_order() use
kvm: iommu: fix the third parameter of kvm_iommu_put_pages (CVE-2014-3601)
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: Daniel Drake <drake@endlessm.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Tested-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Olof 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: Daniel Drake <drake@endlessm.com>
Tested-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Olof 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 2a8f45b040.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Now that we support 48-bit physical addressing, update MAX_PHYSMEM_BITS
accordingly.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@caviumnetworks.com>
Signed-off-by: Will 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: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Will 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: Mark Brown <broonie@linaro.org>
Signed-off-by: Will 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: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will 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: Aaro Koskinen <aaro.koskinen@nsn.com>
Cc: stable@vger.kernel.org
Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7437/
Signed-off-by: James 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: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7424/
Signed-off-by: James 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: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7423/
Signed-off-by: James 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: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7422/
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Commit 4c21b8fd8f (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: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7481/
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: James 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: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: http://patchwork.linux-mips.org/patch/7480/
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: James Hogan <james.hogan@imgtec.com>
In preemptible kernel, only TIF_USEDFPU flag is reliable to distinguish
whether _init_fpu()/_restore_fp() is needed. Because the value of the
CP0_Status.CU1 isn't changed during preemption.
V2: Fix coding style.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: John Crispin <john@phrozen.org>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Patchwork: https://patchwork.linux-mips.org/patch/7515/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The nlm_xlp_defconfig build fails with
./arch/mips/include/asm/mach-netlogic/topology.h:15:0:
error: "topology_core_id" redefined [-Werror]
In file included from include/linux/smp.h:59:0,
[ ...]
from arch/mips/mm/dma-default.c:12:
./arch/mips/include/asm/smp.h:41:0:
note: this is the location of the previous definition
and similar errors.
This is caused by commit bda4584cd9 ("MIPS: Support CPU topology files
in sysfs") which adds the defines to arch/mips/include/asm/smp.h.
Remove the defines from arch/mips/include/asm/mach-netlogic/topology.h
as no longer necessary.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7513/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This reverts commit 682367c494,
which causes 32-bit SMP Windows 7 guests to panic.
SeaBIOS has a limit on the number of MTRRs that it can handle,
and this patch exceeded the limit. Better revert it.
Thanks to Nadav Amit for debugging the cause.
Cc: stable@nongnu.org
Reported-by: Wanpeng Li <wanpeng.li@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This reverts the check added by commit 5045b46803 (KVM: x86: check CS.DPL
against RPL during task switch, 2014-05-15). Although the CS.DPL=CS.RPL
check is mentioned in table 7-1 of the SDM as causing a #TSS exception,
it is not mentioned in table 6-6 that lists "invalid TSS conditions"
which cause #TSS exceptions. In fact it causes some tests to fail, which
pass on bare-metal.
Keep the rest of the commit, since we will find new uses for it in 3.18.
Reported-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
