- 03 Aug, 2016 3 commits
-
-
Andrea Gelmini authored
Signed-off-by:
Andrea Gelmini <andrea.gelmini@gelma.net> Cc: trivial@kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13316/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Andrea Gelmini authored
Signed-off-by:
-
Sudip Mukherjee authored
Some configs of mips like xway_defconffig are failing with the error: arch/mips/lantiq/irq.c:209:2: error: initialization from incompatible pointer type [-Werror] "icu", ^ arch/mips/lantiq/irq.c:209:2: error: (near initialization for 'ltq_irq_type.parent_device') [-Werror] arch/mips/lantiq/irq.c:219:2: error: initialization from incompatible pointer type [-Werror] "eiu", ^ arch/mips/lantiq/irq.c:219:2: error: (near initialization for 'ltq_eiu_type.parent_device') [-Werror] The first member of the "struct irq" is no longer a pointer for the name. Fixes: be45beb2 ("genirq: Add runtime power management support for IRQ chips") Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Acked-by:
John Crispin <john@phrozen.org> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13684/Signed-off-by:
-
- 02 Aug, 2016 10 commits
-
-
Paul Burton authored
Use CPHYSADDR to implement the __pa macro converting from a virtual to a physical address for MIPS32, much as is already done for MIPS64 (though without the complication of having both compatibility & XKPHYS segments). This allows for __pa to work regardless of whether the address being translated is in kseg0 or kseg1, unlike the previous subtraction based approach which only worked for addresses in kseg0. Working for kseg1 addresses is important if __pa is used on addresses allocated by dma_alloc_coherent, where on systems with non-coherent I/O we provide addresses in kseg1. If this address is then used with dma_map_single_attrs then it is provided to virt_to_page, which in turn calls virt_to_phys which is a wrapper around __pa. The result is that we end up with a physical address 0x20000000 bytes (ie. the size of kseg0) too high. In addition to providing consistency with MIPS64 & fixing the kseg1 case above this has the added bonus of generating smaller code for systems implementing MIPS32r2 & beyond, where a single ext instruction can extract the physical address rather than needing to load an immediate into a temp register & subtract it. This results in ~1.3KB savings for a boston_defconfig kernel adjusted to set CONFIG_32BIT=y. This patch does not change the EVA case, which may or may not have similar issues around handling both cached & uncached addresses but is beyond the scope of this patch. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13836/Signed-off-by:
-
Aaro Koskinen authored
Add more leds discovered by reverse engineering. Labels are according to markings in the mechanics. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13466/Signed-off-by:
-
Aaro Koskinen authored
Clean up GPIO definitions in dlink_dsr-1000n.dts. Signed-off-by:
-
Aaro Koskinen authored
Users will get more complete functionality by using the appended DTB, so delete the legacy booting support for this board. Signed-off-by:
-
Jonas Gorski authored
Instead of rewriting the arguments to match the UHI spec, store the address of a appended or UHI supplied dtb in fw_supplied_dtb. That way the original bootloader arugments are kept intact while still making the use of an appended dtb invisible for mach code. Mach code can still find out if it is an appended dtb by comparing fw_arg1 with fw_supplied_dtb. Signed-off-by:
Jonas Gorski <jogo@openwrt.org> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: John Crispin <john@phrozen.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Alban Bedel <albeu@free.fr> Cc: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us> Cc: Antony Pavlov <antonynpavlov@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13699/Signed-off-by:
-
Jonas Gorski authored
Instead of rewriting the arguments, just move the appended dtb to where the decompressed kernel expects it. This eliminates the need for special casing vmlinuz.bin appended dtb files. Signed-off-by:
-
Álvaro Fernández Rojas authored
pwm function for spis conflicts with uart2 and uart1, fix this by changing it to pwm_uart2, which reflects the real use of these pins with these pinmux (2 for pwm and 2 for uart). Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Cc: john@phrozen.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13369/Signed-off-by:
-
Harvey Hunt authored
The commit ebb5e78c ("MIPS: Initial implementation of a VDSO") caused building a 64 bit kernel with support for n32 and not o32 to produce a build error: arch/mips/kernel/signal32.c:415:11: error: ‘vdso_image_o32’ undeclared here (not in a function) .vdso = &vdso_image_o32, Fix this by moving the o32 specific code into signal_o32.c and updating the Makefile accordingly. Signed-off-by:
Harvey Hunt <harvey.hunt@imgtec.com> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Alex Smith <alex@alex-smith.me.uk> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13690/Signed-off-by:
-
Paul Burton authored
The stack and heap have both been executable by default on MIPS until now. This patch changes the default to be non-executable, but only for ELF binaries with a non-executable PT_GNU_STACK header present. This does apply to both the heap & the stack, despite the name PT_GNU_STACK, and this matches the behaviour of other architectures like ARM & x86. Current MIPS toolchains do not produce the PT_GNU_STACK header, which means that we can rely upon this patch not changing the behaviour of existing binaries. The new default will only take effect for newly compiled binaries once toolchains are updated to support PT_GNU_STACK, and since those binaries are newly compiled they can be compiled expecting the change in default behaviour. Again this matches the way in which the ARM & x86 architectures handled their implementations of non-executable memory. Signed-off-by:
-
Paul Burton authored
In some cases the kernel needs to execute an instruction from the delay slot of an emulated branch instruction. These cases include: - Emulated floating point branch instructions (bc1[ft]l?) for systems which don't include an FPU, or upon which the kernel is run with the "nofpu" parameter. - MIPSr6 systems running binaries targeting older revisions of the architecture, which may include branch instructions whose encodings are no longer valid in MIPSr6. Executing instructions from such delay slots is done by writing the instruction to memory followed by a trap, as part of an "emuframe", and executing it. This avoids the requirement of an emulator for the entire MIPS instruction set. Prior to this patch such emuframes are written to the user stack and executed from there. This patch moves FP branch delay emuframes off of the user stack and into a per-mm page. Allocating a page per-mm leaves userland with access to only what it had access to previously, and compared to other solutions is relatively simple. When a thread requires a delay slot emulation, it is allocated a frame. A thread may only have one frame allocated at any one time, since it may only ever be executing one instruction at any one time. In order to ensure that we can free up allocated frame later, its index is recorded in struct thread_struct. In the typical case, after executing the delay slot instruction we'll execute a break instruction with the BRK_MEMU code. This traps back to the kernel & leads to a call to do_dsemulret which frees the allocated frame & moves the user PC back to the instruction that would have executed following the emulated branch. In some cases the delay slot instruction may be invalid, such as a branch, or may trigger an exception. In these cases the BRK_MEMU break instruction will not be hit. In order to ensure that frames are freed this patch introduces dsemul_thread_cleanup() and calls it to free any allocated frame upon thread exit. If the instruction generated an exception & leads to a signal being delivered to the thread, or indeed if a signal simply happens to be delivered to the thread whilst it is executing from the struct emuframe, then we need to take care to exit the frame appropriately. This is done by either rolling back the user PC to the branch or advancing it to the continuation PC prior to signal delivery, using dsemul_thread_rollback(). If this were not done then a sigreturn would return to the struct emuframe, and if that frame had meanwhile been used in response to an emulated branch instruction within the signal handler then we would execute the wrong user code. Whilst a user could theoretically place something like a compact branch to self in a delay slot and cause their thread to become stuck in an infinite loop with the frame never being deallocated, this would: - Only affect the users single process. - Be architecturally invalid since there would be a branch in the delay slot, which is forbidden. - Be extremely unlikely to happen by mistake, and provide a program with no more ability to harm the system than a simple infinite loop would. If a thread requires a delay slot emulation & no frame is available to it (ie. the process has enough other threads that all frames are currently in use) then the thread joins a waitqueue. It will sleep until a frame is freed by another thread in the process. Since we now know whether a thread has an allocated frame due to our tracking of its index, the cookie field of struct emuframe is removed as we can be more certain whether we have a valid frame. Since a thread may only ever have a single frame at any given time, the epc field of struct emuframe is also removed & the PC to continue from is instead stored in struct thread_struct. Together these changes simplify & shrink struct emuframe somewhat, allowing twice as many frames to fit into the page allocated for them. The primary benefit of this patch is that we are now free to mark the user stack non-executable where that is possible. Signed-off-by:
-
- 01 Aug, 2016 1 commit
-
-
Amitoj Kaur Chawla authored
debugfs_create_file returns NULL on error so an IS_ERR test is incorrect here and a NULL check is required. The Coccinelle semantic patch used to make this change is as follows: @@ expression e; @@ e = debugfs_create_file(...); if( - IS_ERR(e) + !e ) { <+... return - PTR_ERR(e) + -ENOMEM ; ...+> } Signed-off-by:Amitoj Kaur Chawla <amitoj1606@gmail.com> Cc: julia.lawall@lip6.fr Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13834/Signed-off-by:
-
- 29 Jul, 2016 13 commits
-
-
James Hogan authored
The MIPS Coherence Manager (CM) can propagate address-based ("hit") cache operations to other cores in the coherent system, alleviating software of the need to use SMP calls, however indexed cache operations are not propagated by hardware since doing so makes no sense for separate caches. Update r4k_op_needs_ipi() to report that only hit cache operations are globalized by the CM, requiring indexed cache operations to be globalized by software via an SMP call. r4k_on_each_cpu() previously had a special case for CONFIG_MIPS_MT_SMP, intended to avoid the SMP calls when the only other CPUs in the system were other VPEs in the same core, and hence sharing the same caches. This was changed by commit cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores") to apparently handle multi-core multi-VPE systems, but it focussed mainly on hit cache ops, so the SMP calls were still disabled entirely for CM systems. This doesn't normally cause problems, but tests can be written to hit these corner cases by using multiple threads, or changing task affinities to force the process to migrate cores. For example the failure of mprotect RW->RX to globally sync icaches (via flush_cache_range) can be detected by modifying and mprotecting a code page on one core, and migrating to a different core to execute from it. Signed-off-by:James Hogan <james.hogan@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13807/Signed-off-by:
-
James Hogan authored
Avoid SMP calls for flushing small icache ranges. On non-CM platforms, and CM platforms too after we make r4k_on_each_cpu() take the cache op type into account, it will be called on multiple CPUs due to the possibility that local_r4k_flush_icache_range_ipi() could do non-globalized indexed cache ops. This rougly copies the range size check out into r4k_flush_icache_range(), which can disallow indexed cache ops and allow r4k_on_each_cpu() to skip the SMP call. Signed-off-by:
-
James Hogan authored
Allow the permitted cache op types used by local_r4k_flush_icache_range_ipi() to be overridden by the SMP caller. This will allow SMP calls to be avoided under certain circumstances, falling back to a single CPU performing globalized hit cache ops only. Signed-off-by:
-
James Hogan authored
Split the operation of r4k_flush_kernel_vmap_range() into separate SMP callbacks for the indexed cache flush and hit cache flush cases, since the logic to determine which to use can be determined by the initiating CPU prior to doing any SMP calls. This will help when we change r4k_on_each_cpu() to distinguish indexed and hit cache ops in a later patch, preventing globalized hit cache ops being performed redundantly on multiple CPUs. Signed-off-by:
-
James Hogan authored
When performing SMP calls to foreign cores, exclude sibling CPUs from the provided map, as we already handle the local core on the current CPU. This prevents an SMP call from for example core 0, VPE 1 to VPE 0 on the same core. In the process the cpu_foreign_map cpumask is turned into an array of cpumasks, so that each CPU has its own version of it which excludes sibling CPUs. r4k_op_needs_ipi() is also updated to reflect that cache management SMP calls are not needed when all CPUs are siblings (i.e. there are no foreign CPUs according to the new cpu_foreign_map[] semantics which exclude siblings). Signed-off-by:
-
James Hogan authored
Several cache operations are optimised to return early from the SMP call handler if the memory map in question has no valid ASID on the current CPU, or any online CPU in the case of MIPS_MT_SMP. The idea is that if a memory map has never been used on a CPU it shouldn't have cache lines in need of flushing. However this doesn't cover all cases when ASIDs for other CPUs need to be checked: - Offline VPEs may have recently been online and brought lines into the (shared) cache, so they should also be checked, rather than only online CPUs. - SMP systems with a Coherence Manager (CM), but with MT disabled still have globalized hit cache ops, but don't use SMP calls, so all present CPUs should be taken into account. - R6 systems have a different multithreading implementation, so MIPS_MT_SMP won't be set, but as above may still have a CM which globalizes hit cache ops. Additionally for non-globalized cache operations where an SMP call to a single VPE in each foreign core is used, it is not necessary to check every CPU in the system, only sibling CPUs sharing the same first level cache. Fix this by making has_valid_asid() take a cache op type argument like r4k_on_each_cpu(), so it can determine whether r4k_on_each_cpu() will have done SMP calls to other cores. It can then determine which set of CPUs to check the ASIDs of based on that, excluding foreign CPUs if an SMP call will have been performed. Signed-off-by:
-
James Hogan authored
The r4k_on_each_cpu() function calls the specified cache flush helper on other CPUs if deemed necessary due to the cache ops not being globalized by hardware. However this really depends on the cache op addressing type, as the MIPS Coherence Manager (CM) if present will globalize "hit" cache ops (addressed by virtual address), but not "index" cache ops (addressed by cache index). This results in index cache ops only being performed on a single CPU when CM is present. Most (but not all) of the functions called by r4k_on_each_cpu() perform cache operations exclusively with a single cache op type, so add a type argument and modify the callers to pass in some combination of R4K_HIT (global kernel virtual addressing or user virtual addressing conditional upon matching active_mm) and R4K_INDEX (index into cache). This will allow r4k_on_each_cpu() to later distinguish these cases and decide whether to perform an SMP call based on it. Signed-off-by:
-
James Hogan authored
Avoid the dcache and scache flush in local_r4k_flush_cache_sigtramp() if the icache fills straight from the dcache. Signed-off-by:
-
James Hogan authored
Fix r4k_flush_cache_sigtramp() and local_r4k_flush_cache_sigtramp() to flush the delay slot emulation trampoline cacheline through a kmap rather than directly when the active_mm doesn't match that of the task initiating the flush, a bit like local_r4k_flush_cache_page() does. This would fix a corner case on SMP systems without hardware globalized hit cache ops, where a migration to another CPU after the flush, where that CPU did not have the same mm active at the time of the flush, could result in stale icache content being executed instead of the trampoline, e.g. from a previous delay slot emulation with a similar stack pointer. This case was artificially triggered by replacing the icache flush with a full indexed flush (not globalized on CM systems) and forcing the SMP call to take place, with a test program that alternated two FPU delay slots with a parent process repeatedly changing scheduler affinity. Signed-off-by:
-
James Hogan authored
The protected_writeback_scache_line() function is used by local_r4k_flush_cache_sigtramp() to flush an FPU delay slot emulation trampoline on the userland stack from the caches so it is visible to subsequent instruction fetches. Commit de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions") updated some protected_ cache flush functions to use EVA CACHEE instructions via protected_cachee_op(), and commit 83fd4344 ("MIPS: r4kcache: Add EVA case for protected_writeback_dcache_line") did the same thing for protected_writeback_dcache_line(), but protected_writeback_scache_line() never got updated. Lets fix that now to flush the right user address from the secondary cache rather than some arbitrary kernel unmapped address. This issue was spotted through code inspection, and it seems unlikely to be possible to hit this in practice. It theoretically affect EVA kernels on EVA capable cores with an L2 cache, where the icache fetches straight from RAM (cpu_icache_snoops_remote_store == 0), running a hard float userland with FPU disabled (nofpu). That both Malta and Boston platforms override cpu_icache_snoops_remote_store to 1 suggests that all MIPS cores fetch instructions into icache straight from L2 rather than RAM. Fixes: de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions") Signed-off-by:
-
James Hogan authored
Commit cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores") added the cpu_foreign_map cpumask containing a single VPE from each online core, and recalculated it when secondary CPUs are brought up. stop_this_cpu() was also updated to recalculate cpu_foreign_map, but with an additional hack before marking the CPU as offline to copy cpu_online_mask into cpu_foreign_map and perform an SMP memory barrier. This appears to have been intended to prevent cache management IPIs being missed when the VPE representing the core in cpu_foreign_map is taken offline while other VPEs remain online. Unfortunately there is nothing in this hack to prevent r4k_on_each_cpu() from reading the old cpu_foreign_map, and smp_call_function_many() from reading that new cpu_online_mask with the core's representative VPE marked offline. It then wouldn't send an IPI to any online VPEs of that core. stop_this_cpu() is only actually called in panic and system shutdown / halt / reboot situations, in which case all CPUs are going down and we don't really need to care about cache management, so drop this hack. Note that the __cpu_disable() case for CPU hotplug is handled in the previous commit, and no synchronisation is needed there due to the use of stop_machine() which prevents hotplug from taking place while any CPU has disabled preemption (as r4k_on_each_cpu() does). Signed-off-by:
-
James Hogan authored
When a CPU is disabled via CPU hotplug, cpu_foreign_map is not updated. This could result in cache management SMP calls being sent to offline CPUs instead of online siblings in the same core. Add a call to calculate_cpu_foreign_map() in the various MIPS cpu disable callbacks after set_cpu_online(). All cases are updated for consistency and to keep cpu_foreign_map strictly up to date, not just those which may support hardware multithreading. Fixes: cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores") Signed-off-by:
-
James Hogan authored
The SMP flush_tlb_*() functions may clear the memory map's ASIDs for other CPUs if the mm has only a single user (the current CPU) in order to avoid SMP calls. However this makes it appear to has_valid_asid(), which is used by various cache flush functions, as if the CPUs have never run in the mm, and therefore can't have cached any of its memory. For flush_tlb_mm() this doesn't sound unreasonable. flush_tlb_range() corresponds to flush_cache_range() which does do full indexed cache flushes, but only on the icache if the specified mapping is executable, otherwise it doesn't guarantee that there are no cache contents left for the mm. flush_tlb_page() corresponds to flush_cache_page(), which will perform address based cache ops on the specified page only, and also only touches the icache if the page is executable. It does not guarantee that there are no cache contents left for the mm. For example, this affects flush_cache_range() which uses the has_valid_asid() optimisation. It is required to flush the icache when mappings are made executable (e.g. using mprotect) so they are immediately usable. If some code is changed to non executable in order to be modified then it will not be flushed from the icache during that time, but the ASID on other CPUs may still be cleared for TLB flushing. When the code is changed back to executable, flush_cache_range() will assume the code hasn't run on those other CPUs due to the zero ASID, and won't invalidate the icache on them. This is fixed by clearing the other CPUs ASIDs to 1 instead of 0 for the above two flush_tlb_*() functions when the corresponding cache flushes are likely to be incomplete (non executable range flush, or any page flush). This ASID appears valid to has_valid_asid(), but still triggers ASID regeneration due to the upper ASID version bits being 0, which is less than the minimum ASID version of 1 and so always treated as stale. Signed-off-by:
-
- 28 Jul, 2016 6 commits
-
-
James Hogan authored
AT_VECTOR_SIZE_ARCH should be defined with the maximum number of NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined for MIPS at all even though ARCH_DLINFO will contain one NEW_AUX_ENT for the VDSO address. This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for AT_BASE_PLATFORM which MIPS doesn't use, but lets define it now and add the comment above ARCH_DLINFO as found in several other architectures to remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to date. Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO") Signed-off-by:
-
Steven J. Hill authored
At boot time, do a better job of resetting the USB host controller to make the frequency "eye" diagram more compliant with the USB standard while making the controller more reliable. Signed-off-by:
Steven J. Hill <steven.hill@cavium.com> Acked-by:
David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13831/Signed-off-by:
-
Steven J. Hill authored
Set the DMA mask such that all descriptors stay in the lower 4GB of memory. Signed-off-by:
-
Steven J. Hill authored
Get rid of unnecessary forced interrupt mappings for the USB host controller on OCTEON II. Signed-off-by:
-
David Howells authored
MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than calling sys_keyctl. The latter will work in a lot of cases, thereby hiding the issue. Reported-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
David Howells <dhowells@redhat.com> cc: stable@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: linux-security-module@vger.kernel.org Cc: keyrings@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13832/Signed-off-by:
-
James Hogan authored
Currently the debugfs interface to print the segment configuration refuses to print the physical address of mapped segments. However if the EU bit is set these become unmapped at error level (when CP0_Status.ERL=1), so the physical address is still relevant. Update the logic to print the physical address of mapped segments when the EU bit is set, while still hiding the Cache Coherency Attribute (since EU overrides that to uncached when ERL=1 too). Signed-off-by:
-
- 24 Jul, 2016 7 commits
-
-
James Hogan authored
The expression "uasm_in_compat_space_p(swpd) && !uasm_rel_lo(swpd)" is used twice in build_get_pgd_vmalloc64(), one of which is assigned to the local variable single_insn_swpd. Update the other use to just use single_insn_swpd instead to remove the duplication. Signed-off-by:
-
James Hogan authored
uasm_in_compat_space_p() determines whether the given value is in the 32-bit compatibility part of the 64-bit address space, i.e. is in 32-bit sign-extended form, however it only handles the top half of the value space (corresponding to the kernel compatibility segments in the upper half of the address space). Since values < 2^31 (corresponding to the low 2GiB of the address space) can also be handled using 32-bit instructions (e.g. a LUI and ADDIU) rather than convoluted 64-bit immediate generation, rewrite it with a cast to check whether the address matches its 32-bit sign extended form. This allows UASM_i_LA to be used to generate arbitrary 32-bit immediates more efficiently on 64-bit CPUs, i.e. more like the li (load immediate) pseudo-instruction. For example this code to load the immediate (ST0_EXL | KSU_USER | ST0_BEV | ST0_KX) into k0 with UASM_i_LA(): lui k0,0x0 dsll k0,k0,0x10 daddiu k0,k0,64 dsll k0,k0,0x10 daddiu k0,k0,146 Changes to this more efficient version: lui k0,0x40 addiu k0,k0,146 Signed-off-by:
-
Sergey Ryazanov authored
Signed-off-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Cc: Linux MIPS <linux-mips@linux-mips.org> Patchwork: https://patchwork.linux-mips.org/patch/13700/Signed-off-by:
-
James Hartley authored
The Pistachio SoC from Imagination Technologies currently has no entry in the MAINTAINERS file, so add one. Signed-off-by:
James Hartley <james.hartley@imgtec.com> Reviewed-by:
Ionela Voinescu <ionela.voinescu@imgtec.com> Cc: davem@davemloft.net Cc: geert@linux-m68k.org Cc: gregkh@linuxfoundation.org Cc: akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: ionela.voinescu@imgtec.com Patchwork: https://patchwork.linux-mips.org/patch/13755/Signed-off-by:
-
Zubair Lutfullah Kakakhel authored
The Pistachio SoC does not have an IOCU. Hence, DMA is non-coherent. Remove the function checking for iocoherency and select CONFIG_DMA_NONCOHERENT in Kconfig This code is probably accidentally inherited from Malta. Signed-off-by:
Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Reviewed-by:
-
Linus Walleij authored
The Loongson1 added a new instance of ARCH_WANT_OPTIONAL_GPIOLIB which is no longer required to have GPIOLIB available in Kconfig. Delete it. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13543/Signed-off-by:
-
John Crispin authored
We runtime load the available external interrupts into an array and store the number inside exin_avail. Some of the code however uses MAX_EIU for looping over the array which may partially be 0. This is a cosmetic fix as the existing code works as is. It is just nicer to only loop over the array elements that were actually populated during probe. Signed-off-by:
-
