- 24 Jul, 2014 3 commits
-
-
Marc Carino authored
Perform any CPU-specific initialization required on the Broadcom Brahma-15 core. Signed-off-by: Marc Carino <marc.ceeeee@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Steven Capper authored
For LPAE, we have the following means for encoding writable or dirty ptes: L_PTE_DIRTY L_PTE_RDONLY !pte_dirty && !pte_write 0 1 !pte_dirty && pte_write 0 1 pte_dirty && !pte_write 1 1 pte_dirty && pte_write 1 0 So we can't distinguish between writeable clean ptes and read only ptes. This can cause problems with ptes being incorrectly flagged as read only when they are writeable but not dirty. This patch renumbers L_PTE_RDONLY from AP[2] to a software bit #58, and adds additional logic to set AP[2] whenever the pte is read only or not dirty. That way we can distinguish between clean writeable ptes and read only ptes. HugeTLB pages will use this new logic automatically. We need to add some logic to Transparent HugePages to ensure that they correctly interpret the revised pgprot permissions (L_PTE_RDONLY has moved and no longer matches PMD_SECT_AP2). In the process of revising THP, the names of the PMD software bits have been prefixed with L_ to make them easier to distinguish from their hardware bit counterparts. Signed-off-by: Steve Capper <steve.capper@linaro.org> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Steven Capper authored
Long descriptors on ARM are 64 bits, and some pte functions such as pte_dirty return a bitwise-and of a flag with the pte value. If the flag to be tested resides in the upper 32 bits of the pte, then we run into the danger of the result being dropped if downcast. For example: gather_stats(page, md, pte_dirty(*pte), 1); where pte_dirty(*pte) is downcast to an int. This patch introduces a new macro pte_isset which performs the bitwise and, then performs a double logical invert (where needed) to ensure predictable downcasting. The logical inverse pte_isclear is also introduced. Equivalent pmd functions for Transparent HugePages have also been added. Signed-off-by: Steve Capper <steve.capper@linaro.org> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 18 Jul, 2014 23 commits
-
-
Shawn Guo authored
The CP15 diagnostic register holds ARM errata bits on Cortex-A9, so it needs to be saved/restored on suspend/resume. Otherwise, the effectiveness of errata workaround gets lost together with diagnostic register bit across suspend/resume cycle. And the CP15 power control register of Cortex-A9 shares the same problem. The patch adds a couple of Cortex-A9 specific suspend/resume functions to save/restore these two Cortex-A9 CP15 registers across the suspend/resume cycle. Signed-off-by: Shawn Guo <shawn.guo@freescale.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Will Deacon authored
This patch introduces a wfe-based polling loop for spinning on contended MCS locks and waking up corresponding waiters when the lock is released. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Daniel Thompson authored
Recent contributions, including to DRM and binder, introduce 64-bit values in their interfaces. A common motivation for this is to allow the same ABI for 32- and 64-bit userspaces (and therefore also a shared ABI for 32/64 hybrid userspaces). Anyhow, the developers would like to avoid gotchas like having to use copy_from_user(). This feature is already implemented on x86-32 and the majority of other 32-bit architectures. The current list of get_user_8 hold out architectures are: arm, avr32, blackfin, m32r, metag, microblaze, mn10300, sh. Credit: My name sits rather uneasily at the top of this patch. The v1 and v2 versions of the patch were written by Rob Clark and to produce v4 I mostly copied code from Russell King and H. Peter Anvin. However I have mangled the patch sufficiently that *blame* is rightfully mine even if credit should more widely shared. Changelog: v5: updated to use the ret macro (requested by Russell King) v4: remove an inlined add on big endian systems (spotted by Russell King), used __ARMEB__ rather than BIG_ENDIAN (to match rest of file), cleared r3 on EFAULT during __get_user_8. v3: fix a couple of checkpatch issues v2: pass correct size to check_uaccess, and better handling of narrowing double word read with __get_user_xb() (Russell King's suggestion) v1: original Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Baruch Siach authored
Commit cb8db5d4 (UAPI: (Scripted) Disintegrate arch/arm/include/asm) moved these syscall comments out of their context into the UAPI headers. Fix this. Fixes: cb8db5d4 ("UAPI: (Scripted) Disintegrate arch/arm/include/asm") Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Daniel Thompson authored
The section of the makefile that determines the TEXT_OFFSET is sorted by address so that, in multi-arch kernel builds, the architecture with the most stringent requirements for the kernel base address gets to define TEXT_OFFSET. The comment should reflect that. Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Shawn Guo authored
Add revision info for PL310_ERRATA_588369 and PL310_ERRATA_727915 to help people understand if they need to enable the errata for their hardware. Signed-off-by: Shawn Guo <shawn.guo@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Shawn Guo authored
Since pj4b suspend/resume routines are implemented based on generic ARMv7 ones, instead of hard-coding cpu_pj4b_suspend_size, we should have it be cpu_v7_suspend_size plus pj4b specific bytes. Otherwise, if cpu_v7_suspend_size gets updated alone, the pj4b suspend/resume will likely be broken. While at it, fix the comments in cpu_pj4b_do_resume, as we're restoring CP15 registers rather than saving in there. Signed-off-by: Shawn Guo <shawn.guo@freescale.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Mark Rutland authored
Commit 78d7530a ("ARM: Clean up linker script using new linker script macros.") modified the arm kernel linker script to use the STABS_DEBUG macro, but left a .comment section definition. As STABS_DEBUG defines the .comment section in an identical way, the second section definition is redundant and can be removed. This patch removes the redundant .comment section definition. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nikolay Borisov authored
Use the newly introduced API so that FP is correctly referenced from either R7/R11 based on whether we are running in THUMB2 mode or not. Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Robert Richter <rric@kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nikolay Borisov authored
Use the newly-introduced frame_pointer macro to extract the correct FP based on whether we are in THUMB2 mode or not. Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nikolay Borisov authored
Make the unwind code use the correct API so that the frame pointer is extracted from the correct register. Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nikolay Borisov authored
Make use of the arm_get_current_stackframe api so that the frame pointer is correctly referenced in THUMB2 mode Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nikolay Borisov authored
Make the perf backend use the API so that it correctly references the FP when in THUMB2 mode Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nikolay Borisov authored
Currently there are numerous places where "struct pt_regs" are used to populate "struct stackframe", however all of those location do not consider the situation where the kernel might be compiled in THUMB2 mode, in which case the framepointer member of pt_regs become ARM_r7 instead of ARM_fp (r11). Document this idiosyncracy in the definition of "struct stackframe" The easiest solution is to introduce a new function (in the spirit of https://groups.google.com/forum/#!topic/linux.kernel/dA2YuUcSpZ4) which would hide the complexity of initializing the stackframe struct from pt_regs. Also implement a macro frame_pointer(regs) that would return the correct register so that we can use it in cases where we just require the frame pointer and not a whole struct stackframe Signed-off-by: Nikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Robert Richter <rric@kernel.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nicolas Pitre authored
With patch #8067/1 ("zImage: ensure header in LE format for BE8 kernels") applied, it is no longer possible to determine the endianness of a compiled kernel image. This normally shouldn't matter to the boot environment, except for those cases where the selection of a ramdisk or root filesystem with a matching endianness has to be automated. Let's add a flag to the zImage header indicating the actual endianness. Four bytes from offset 0x30 can be interpreted as follows: 04 03 02 01 big endian kernel 01 02 03 04 little endian kernel Anything else should be interpreted as "unknown", in which case it is most likely that patch #8067/1 was not applied either and the zImage magic number at offset 0x24 could be used instead to determine endianness. No zImage before this patch ever produced 0x01020304 nor 0x04030201 at offset 0x30 so there is no confusion possible. Signed-off-by: Nicolas Pitre <nico@linaro.org> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Save and report (via the procfs file) the last kernel unaligned fault location. This allows us to trivially inspect where the last fault happened for cases which we don't expect to occur. Since we expect the kernel to generate misalignment faults (due to the networking layer), even when warnings are enabled, we don't log them for the kernel. Tested-by: Tony Lindgren <tony@atomide.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
ARMv6 and greater introduced a new instruction ("bx") which can be used to return from function calls. Recent CPUs perform better when the "bx lr" instruction is used rather than the "mov pc, lr" instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro "ret" with all its variants for the condition code which will resolve to the appropriate instruction. Rather than doing this piecemeal, and miss some instances, change all the "mov pc" instances to use the new macro, with the exception of the "movs" instruction and the kprobes code. This allows us to detect the "mov pc, lr" case and fix it up - and also gives us the possibility of deploying this for other registers depending on the CPU selection. Reported-by: Will Deacon <will.deacon@arm.com> Tested-by: Stephen Warren <swarren@nvidia.com> # Tegra Jetson TK1 Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> # mioa701_bootresume.S Tested-by: Andrew Lunn <andrew@lunn.ch> # Kirkwood Tested-by: Shawn Guo <shawn.guo@freescale.com> Tested-by: Tony Lindgren <tony@atomide.com> # OMAPs Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> # Armada XP, 375, 385 Acked-by: Sekhar Nori <nsekhar@ti.com> # DaVinci Acked-by: Christoffer Dall <christoffer.dall@linaro.org> # kvm/hyp Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> # PXA3xx Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> # Xen Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # ARMv7M Tested-by: Simon Horman <horms+renesas@verge.net.au> # Shmobile Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Ensure that platform maintainers check the CPU part number in the right manner: the CPU part number is meaningless without also checking the CPU implement(e|o)r (choose your preferred spelling!) Provide an interface which returns both the implementer and part number together, and update the definitions to include the implementer. Mark the old function as being deprecated... indeed, using the old function with the definitions will now always evaluate as false, so people must update their un-merged code to the new function. While this could be avoided by adding new definitions, we'd also have to create new names for them which would be awkward. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Krzysztof Kozlowski authored
Building of EXYNOS5420_MCPM with disabled SUSPEND fails: arch/arm/mach-exynos/built-in.o: In function `exynos_mcpm_init': arch/arm/mach-exynos/mcpm-exynos.c:361: undefined reference to `mcpm_loopback' The exynos_mcpm_init() in mcp-exynos.c calls mcpm_loopback() which depends on cpu_suspend function (ARM_CPU_SUSPEND). Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nicolas Pitre authored
The Chromebook firmware doesn't enable the CCI for the boot cpu, and arguably it shouldn't have to either. Let's have the kernel handle the CCI on its own for the boot CPU the same way it does it for secondary CPUs by using the MCPM loopback. This allows to boot all 8 cores on exynos5420-peach-pit, exynos5800-peach-pi and ARM Chromebook 2. Signed-off-by: Nicolas Pitre <nico@linaro.org> Tested-by: Tushar Behera <tushar.b@samsung.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> Tested-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nicolas Pitre authored
This is not strictly needed on TC2 but still a good idea to exercise that code. Signed-off-by: nicolas Pitre <nico@linaro.org> Reviewed-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nicolas Pitre authored
The kernel already has the responsibility to handle resources such as the CCI when hotplugging CPUs, during the booting of secondary CPUs, and when resuming from suspend/idle. It would be more coherent and less confusing if the CCI for the boot CPU (or cluster) was also initialized by the kernel rather than expecting the firmware/bootloader to do it and only in that case. After all, the kernel has all the necessary code already and the bootloader shouldn't have to care at all. The CCI may be turned on only when the cache is off. Leveraging the CPU suspend code to loop back through the low-level MCPM entry point is all that is needed to properly turn on the CCI from the kernel by using the same code as during secondary boot. Let's provide a generic MCPM loopback function that can be invoked by backend initialization code to set things (CCI or similar) on the boot CPU just as it is done for the other CPUs. Signed-off-by: Nicolas Pitre <nico@linaro.org> Reviewed-by: Kevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> Tested-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Arnd Bergmann authored
After applying patch: "ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size" following build failure happens on iop13xx platform: In file included from include/linux/srcu.h:33:0, from include/linux/notifier.h:15, from include/linux/reboot.h:5, from arch/arm/mach-iop13xx/include/mach/iop13xx.h:6, from arch/arm/mach-iop13xx/include/mach/hardware.h:14, from arch/arm/mach-iop13xx/include/mach/memory.h:4, from arch/arm/include/asm/memory.h:24, from arch/arm/include/asm/page.h:163, from arch/arm/include/asm/thread_info.h:17, from include/linux/thread_info.h:54, from include/asm-generic/preempt.h:4, from arch/arm/include/generated/asm/preempt.h:1, from include/linux/preempt.h:18, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/uapi/linux/timex.h:56, from include/linux/timex.h:56, from include/linux/sched.h:19, from arch/arm/kernel/asm-offsets.c:13: include/linux/rcupdate.h: In function '__rcu_read_lock': >> include/linux/rcupdate.h:220:2: error: implicit declaration of function 'preempt_disable' [-Werror=implicit-function-declaration] preempt_disable(); The problem here is recursive header inclusion which could be avoided by removing linux/reboot.h from mach/iop13xxx.h. linux/reboot.h in include/mach/iop13xx.h is needed only for enum reboot_mode, so header it could be replaced with a enum declaration. Whatever patch "ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size" does, I think it's good to avoid unnecessary header inclusion here in any case. Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 01 Jul, 2014 4 commits
-
-
Andrey Ryabinin authored
Changing kernel stack size on arm is not as simple as it should be: 1) THREAD_SIZE macro doesn't respect PAGE_SIZE and THREAD_SIZE_ORDER 2) stack size is hardcoded in get_thread_info macro This patch fixes it by calculating THREAD_SIZE and thread_info address taking into account PAGE_SIZE and THREAD_SIZE_ORDER. Now changing stack size becomes simply changing THREAD_SIZE_ORDER. Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
As we are now using the C preprocessor, we do not need to use sed to edit constants in this file, and then pass the resulting file through the C preprocessor. Instead, rely solely on the C preprocessor to rewrite TEXT_START and BSS_ADDR. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nicolas Pitre authored
All known BE8-capable systems have LE bootloaders, so we need to ensure that the magic number and image start/end values are in little endian format. [ben.dooks@codethink.co.uk: from nico's original email on this subject] [taras.kondratiuk@linaro.org: removed lds.S->lds rule, added target to extra-y] Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
The legacy OMAP DMA API is now deprecated; all remaining users should now convert over ASAP to using the DMA engine API instead of the OMAP private API. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 29 Jun, 2014 10 commits
-
-
Linus Torvalds authored
-
git://ftp.arm.linux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: "Another round of ARM fixes. The largest change here is the L2 changes to work around problems for the Armada 37x/380 devices, where most of the size comes down to comments rather than code. The other significant fix here is for the ptrace code, to ensure that rewritten syscalls work as intended. This was pointed out by Kees Cook, but Will Deacon reworked the patch to be more elegant. The remainder are fairly trivial changes" * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: 8087/1: ptrace: reload syscall number after secure_computing() check ARM: 8086/1: Set memblock limit for nommu ARM: 8085/1: sa1100: collie: add top boot mtd partition ARM: 8084/1: sa1100: collie: revert back to cfi_probe ARM: 8080/1: mcpm.h: remove unused variable declaration ARM: 8076/1: mm: add support for HW coherent systems in PL310 cache
-
Randy Dunlap authored
Note that I don't maintain Documentation/ABI/, Documentation/devicetree/, or the language translation files. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Dan Carpenter authored
These days most people use git to send patches so I have added a section about that. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Will Deacon authored
On the syscall tracing path, we call out to secure_computing() to allow seccomp to check the syscall number being attempted. As part of this, a SIGTRAP may be sent to the tracer and the syscall could be re-written by a subsequent SET_SYSCALL ptrace request. Unfortunately, this new syscall is ignored by the current code unless TIF_SYSCALL_TRACE is also set on the current thread. This patch slightly reworks the enter path of the syscall tracing code so that we always reload the syscall number from current_thread_info()->syscall after the potential ptrace traps. Acked-by: Kees Cook <keescook@chromium.org> Tested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Laura Abbott authored
Commit 1c2f87c2 (ARM: 8025/1: Get rid of meminfo) changed find_limits to use memblock_get_current_limit for calculating the max_low pfn. nommu targets never actually set a limit on memblock though which means memblock_get_current_limit will just return the default value. Set the memblock_limit to be the end of DDR to make sure bounds are calculated correctly. Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Andrea Adami authored
The CFI mapping is now perfect so we can expose the top block, read only. There isn't much to read, though, just the sharpsl_params values. Signed-off-by: Andrea Adami <andrea.adami@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Andrea Adami authored
Reverts commit d26b17ed ARM: sa1100: collie.c: fall back to jedec_probe flash detection Unfortunately the detection was challenged on the defective unit used for tests: one of the NOR chips did not respond to the CFI query. Moreover that bad device needed extra delays on erase-suspend/resume cycles. Tested personally on 3 different units and with feedback of two other users. Signed-off-by: Andrea Adami <andrea.adami@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Nicolas Pitre authored
The sync_phys variable has been replaced by link time computation in mcpm_head.S before the code was submitted upstream. Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Thomas Petazzoni authored
When a PL310 cache is used on a system that provides hardware coherency, the outer cache sync operation is useless, and can be skipped. Moreover, on some systems, it is harmful as it causes deadlocks between the Marvell coherency mechanism, the Marvell PCIe controller and the Cortex-A9. To avoid this, this commit introduces a new Device Tree property 'arm,io-coherent' for the L2 cache controller node, valid only for the PL310 cache. It identifies the usage of the PL310 cache in an I/O coherent configuration. Internally, it makes the driver disable the outer cache sync operation. Note that technically speaking, a fully coherent system wouldn't require any of the other .outer_cache operations. However, in practice, when booting secondary CPUs, these are not yet coherent, and therefore a set of cache maintenance operations are necessary at this point. This explains why we keep the other .outer_cache operations and only ->sync is disabled. While in theory any write to a PL310 register could cause the deadlock, in practice, disabling ->sync is sufficient to workaround the deadlock, since the other cache maintenance operations are only used in very specific situations. Contrary to previous versions of this patch, this new version does not simply NULL-ify the ->sync member, because the l2c_init_data structures are now 'const' and therefore cannot be modified, which is a good thing. Therefore, this patch introduces a separate l2c_init_data instance, called of_l2c310_coherent_data. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-