- 01 10月, 2016 1 次提交
-
-
由 Vineet Gupta 提交于
HS release 3.0 provides for even more flexibility in specifying the volatile address space for mapping peripherals. With HS 2.1 @start was made flexible / programmable - with HS 3.0 even @end can be setup (vs. fixed to 0xFFFF_FFFF before). So add code to reflect that and while at it remove an unused struct defintion Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 14 9月, 2016 1 次提交
-
-
由 Vineet Gupta 提交于
Al reported potential issue with ARC get_user() as it wasn't clearing out destination pointer in case of fault due to bad address etc. Verified using following | { | u32 bogus1 = 0xdeadbeef; | u64 bogus2 = 0xdead; | int rc1, rc2; | | pr_info("Orig values %x %llx\n", bogus1, bogus2); | rc1 = get_user(bogus1, (u32 __user *)0x40000000); | rc2 = get_user(bogus2, (u64 __user *)0x50000000); | pr_info("access %d %d, new values %x %llx\n", | rc1, rc2, bogus1, bogus2); | } | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko | Orig values deadbeef dead | access -14 -14, new values 0 0 Reported-by: NAl Viro <viro@ZenIV.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-snps-arc@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: NVineet Gupta <vgupta@synopsys.com> Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 20 8月, 2016 3 次提交
-
-
由 Vineet Gupta 提交于
| CC mm/memory.o | In file included from ../mm/memory.c:53:0: | ../include/linux/pfn_t.h: In function ‘pfn_t_pte’: | ../include/linux/pfn_t.h:78:2: error: conversion to non-scalar type requested | return pfn_pte(pfn_t_to_pfn(pfn), pgprot); With STRICT_MM_TYPECHECKS pte_t is a struct and the offending code forces a cast which ends up shifting a struct and hence the gcc warning. Note that in recent past some of the arches (aarch64, s390) made STRICT_MM_TYPECHECKS default, but we don't for ARC as this leads to slightly worse generated code, given ARC ABI definition of returning structs (which pte_t would become) Quoting from ARC ABI... "Results of type struct are returned in a caller-supplied temporary variable whose address is passed in r0. For such functions, the arguments are shifted so that they are passed in r1 and up." So - struct to be returned would be allocated on stack requiring extra code at call sites - callee updates stack memory to facilitate the return (vs. simple MOV into return reg r0) Hence STRICT_MM_TYPECHECKS is not enabled by default for ARC Cc: <stable@vger.kernel.org> #4.4+ Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
The syscall ABI includes the gcc functional calling ABI since a syscall implies userland caller and kernel callee. The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in even-odd register pairs, (potentially punching reg holes when passing such values as args). This was partly driven by the fact that the double-word LDD/STD instructions in ARCv2 expect the register alignment and thus gcc forcing this avoids extra MOV at the cost of a few unused register (which we have plenty anyways). This however was rejected as part of upstreaming gcc port to HS. So the new ABI v4 doesn't enforce the even-odd reg restriction. Do note that for ARCompact ISA builds v3 and v4 are practically the same in terms of gcc code generation. In terms of change management, we infer the new ABI if gcc 6.x onwards is used for building the kernel. This also needs a stable backport to enable older kernels to work with new tools/user-space Cc: <stable@vger.kernel.org> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Liav Rehana 提交于
User mode callee regs are explicitly collected before signal delivery or breakpoint trap. r25 is special for kernel as it serves as task pointer, so user mode value is clobbered very early. It is saved in pt_regs where generally only scratch (aka caller saved) regs are saved. The code to access the corresponding pt_regs location had a subtle bug as it was using load/store with scaling of offset, whereas the offset was already byte wise correct. So fix this by replacing LD.AS with a standard LD Cc: <stable@vger.kernel.org> Signed-off-by: NLiav Rehana <liavr@mellanox.com> Reviewed-by: NAlexey Brodkin <abrodkin@synopsys.com> [vgupta: rewrote title and commit log] Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 11 8月, 2016 1 次提交
-
-
由 Daniel Mentz 提交于
trace_hardirqs_on_caller() in lockdep.c expects to be called before, not after interrupts are actually enabled. The following comment in kernel/locking/lockdep.c substantiates this claim: " /* * We're enabling irqs and according to our state above irqs weren't * already enabled, yet we find the hardware thinks they are in fact * enabled.. someone messed up their IRQ state tracing. */ " An example can be found in include/linux/irqflags.h: do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0) Without this change, we hit the following DEBUG_LOCKS_WARN_ON. [ 7.760000] ------------[ cut here ]------------ [ 7.760000] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2711 resume_user_mode_begin+0x48/0xf0 [ 7.770000] DEBUG_LOCKS_WARN_ON(!irqs_disabled()) [ 7.780000] Modules linked in: [ 7.780000] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-00003-gc668bb9-dirty #366 [ 7.790000] [ 7.790000] Stack Trace: [ 7.790000] arc_unwind_core.constprop.1+0xa4/0x118 [ 7.800000] warn_slowpath_fmt+0x72/0x158 [ 7.800000] resume_user_mode_begin+0x48/0xf0 [ 7.810000] ---[ end trace 6f6a7a8fae20d2f0 ]--- Signed-off-by: NDaniel Mentz <danielmentz@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 29 7月, 2016 1 次提交
-
-
由 Vineet Gupta 提交于
LTP madvise05 was generating mm splat | [ARCLinux]# /sd/ltp/testcases/bin/madvise05 | BUG: Bad page map in process madvise05 pte:80e08211 pmd:9f7d4000 | page:9fdcfc90 count:1 mapcount:-1 mapping: (null) index:0x0 flags: 0x404(referenced|reserved) | page dumped because: bad pte | addr:200b8000 vm_flags:00000070 anon_vma: (null) mapping: (null) index:1005c | file: (null) fault: (null) mmap: (null) readpage: (null) | CPU: 2 PID: 6707 Comm: madvise05 And for newer kernels, the system was rendered unusable afterwards. The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is set to identify the special zero page wired to the pte). When pte was finally unmapped, special casing for zero page was not done, and instead it was treated as a "normal" page, tripping on the map counts etc. This fixes ARC STAR 9001053308 Cc: <stable@vger.kernel.org> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 25 6月, 2016 1 次提交
-
-
由 Michal Hocko 提交于
__GFP_REPEAT has a rather weak semantic but since it has been introduced around 2.6.12 it has been ignored for low order allocations. pte_alloc_one_kernel uses __get_order_pte but this is obviously always zero because BITS_FOR_PTE is not larger than 9 yet the page size is always larger than 4K. This means that this flag has never been actually useful here because it has always been used only for PAGE_ALLOC_COSTLY requests. Link: http://lkml.kernel.org/r/1464599699-30131-7-git-send-email-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com> Acked-by: NVineet Gupta <vgupta@synopsys.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 6月, 2016 1 次提交
-
-
由 Peter Zijlstra 提交于
Resolve conflict between commits: fbffe892 ("locking/atomic, arch/arc: Implement atomic_fetch_{add,sub,and,andnot,or,xor}()") and: ed6aefed ("Revert "ARCv2: spinlock/rwlock/atomics: Delayed retry of failed SCOND with exponential backoff"") Reported-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nigel Topham <ntopham@synopsys.com> Cc: Noam Camus <noamc@ezchip.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: linux-kernel@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 16 6月, 2016 2 次提交
-
-
由 Peter Zijlstra 提交于
Since all architectures have this implemented now natively, remove this dead code. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Peter Zijlstra 提交于
Implement FETCH-OP atomic primitives, these are very similar to the existing OP-RETURN primitives we already have, except they return the value of the atomic variable _before_ modification. This is especially useful for irreversible operations -- such as bitops (because it becomes impossible to reconstruct the state prior to modification). Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Acked-by: NVineet Gupta <vgupta@synopsys.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Noam Camus <noamc@ezchip.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 14 6月, 2016 1 次提交
-
-
由 Peter Zijlstra 提交于
This patch updates/fixes all spin_unlock_wait() implementations. The update is in semantics; where it previously was only a control dependency, we now upgrade to a full load-acquire to match the store-release from the spin_unlock() we waited on. This ensures that when spin_unlock_wait() returns, we're guaranteed to observe the full critical section we waited on. This fixes a number of spin_unlock_wait() users that (not unreasonably) rely on this. I also fixed a number of ticket lock versions to only wait on the current lock holder, instead of for a full unlock, as this is sufficient. Furthermore; again for ticket locks; I added an smp_rmb() in between the initial ticket load and the spin loop testing the current value because I could not convince myself the address dependency is sufficient, esp. if the loads are of different sizes. I'm more than happy to remove this smp_rmb() again if people are certain the address dependency does indeed work as expected. Note: PPC32 will be fixed independently Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: chris@zankel.net Cc: cmetcalf@mellanox.com Cc: davem@davemloft.net Cc: dhowells@redhat.com Cc: james.hogan@imgtec.com Cc: jejb@parisc-linux.org Cc: linux@armlinux.org.uk Cc: mpe@ellerman.id.au Cc: ralf@linux-mips.org Cc: realmz6@gmail.com Cc: rkuo@codeaurora.org Cc: rth@twiddle.net Cc: schwidefsky@de.ibm.com Cc: tony.luck@intel.com Cc: vgupta@synopsys.com Cc: ysato@users.sourceforge.jp Cc: linux-kernel@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 02 6月, 2016 3 次提交
-
-
由 Vineet Gupta 提交于
This reverts commit e78fdfef. The issue was fixed in hardware in HS2.1C release and there are no known external users of affected RTL so revert the whole delayed retry series ! Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
This reverts commit b89aa12c. The issue was fixed in hardware in HS2.1C release and there are no known external users of affected RTL so revert the whole delayed retry series ! Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
This reverts commit 10971638. The issue was fixed in hardware in HS2.1C release and there are no known external users of affected RTL - so revert thw whole delayed retry series ! Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 30 5月, 2016 1 次提交
-
-
由 Andrea Gelmini 提交于
Signed-off-by: NAndrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 20 5月, 2016 1 次提交
-
-
由 Hugh Dickins 提交于
I've just discovered that the useful-sounding has_transparent_hugepage() is actually an architecture-dependent minefield: on some arches it only builds if CONFIG_TRANSPARENT_HUGEPAGE=y, on others it's also there when not, but on some of those (arm and arm64) it then gives the wrong answer; and on mips alone it's marked __init, which would crash if called later (but so far it has not been called later). Straighten this out: make it available to all configs, with a sensible default in asm-generic/pgtable.h, removing its definitions from those arches (arc, arm, arm64, sparc, tile) which are served by the default, adding #define has_transparent_hugepage has_transparent_hugepage to those (mips, powerpc, s390, x86) which need to override the default at runtime, and removing the __init from mips (but maybe that kind of code should be avoided after init: set a static variable the first time it's called). Signed-off-by: NHugh Dickins <hughd@google.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andres Lagar-Cavilla <andreslc@google.com> Cc: Yang Shi <yang.shi@linaro.org> Cc: Ning Qu <quning@gmail.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Acked-by: NDavid S. Miller <davem@davemloft.net> Acked-by: Vineet Gupta <vgupta@synopsys.com> [arch/arc] Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [arch/s390] Acked-by: NIngo Molnar <mingo@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 13 5月, 2016 1 次提交
-
-
由 Vineet Gupta 提交于
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 09 5月, 2016 14 次提交
-
-
由 Noam Camus 提交于
The default 256 bytes sometimes is just not enough. We usually provide earlycon=... and console=... and ip=... All this and more may need more room. Signed-off-by: NNoam Camus <noamc@ezchip.com> Acked-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Tal Zilcer 提交于
Since the CTOP is SMT hardware multi-threaded, we need to hint the HW that now will be a very good time to do a hardware thread context switching. This is done by issuing the schd.rw instruction (binary coded here so as to not require specific revision of GCC to build the kernel). sched.rw means that Thread becomes eligible for execution by the threads scheduler after all pending read/write transactions were completed. Implementing cpu_relax_lowlatency() with barrier() Since with current semantics of cpu_relax() it may take a while till yielded CPU will get back. Signed-off-by: NNoam Camus <noamc@ezchip.com> Cc: Peter Zijlstra <peterz@infradead.org> Acked-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Noam Camus 提交于
With generic "identity" num of CPUs is limited to 256 (8 bit). We use our alternative AUX register GLOBAL_ID (12 bit). Now we can support up to 4096 CPUs. Signed-off-by: NNoam Camus <noamc@ezchip.com>
-
由 Noam Camus 提交于
NPS device got 256 cores and each got 16 HW threads (SMT). We use EZchip dedicated ISA to trigger HW scheduler of the core that current HW thread belongs to. This scheduling makes sure that data beyond barrier is available to all HW threads in core and by that to all in device (4K). Signed-off-by: NNoam Camus <noamc@ezchip.com> Cc: Peter Zijlstra <peterz@infradead.org>
-
由 Noam Camus 提交于
We need our own implementaions since we lack LLSC support. Our extended ISA provided with optimized solution for all 32bit operations we see in these three headers. Signed-off-by: NNoam Camus <noamc@ezchip.com>
-
由 Noam Camus 提交于
NPS use special mapping right below TASK_SIZE. Hence we need to lower STACK_TOP so that user stack won't overlap NPS special mapping. Signed-off-by: NNoam Camus <noamc@ezchip.com> Acked-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Noam Camus 提交于
If we hold rwlock and interrupt occures we may end up spinning on it for ever during softirq. Note that this lock is an internal lock and since the lock is free to be used from any context, the lock needs to be IRQ-safe. Below you may see an example for interrupt we get while nl_table_lock is holding its rw->lock_mutex and we spinned on it for ever. The concept for the fix was taken from SPARC. [2015-05-12 19:16:12] Stack Trace: [2015-05-12 19:16:12] arc_unwind_core+0xb8/0x11c [2015-05-12 19:16:12] dump_stack+0x68/0xac [2015-05-12 19:16:12] _raw_read_lock+0xa8/0xac [2015-05-12 19:16:12] netlink_broadcast_filtered+0x56/0x35c [2015-05-12 19:16:12] nlmsg_notify+0x42/0xa4 [2015-05-12 19:16:13] neigh_update+0x1fe/0x44c [2015-05-12 19:16:13] neigh_event_ns+0x40/0xa4 [2015-05-12 19:16:13] arp_process+0x46e/0x5a8 [2015-05-12 19:16:13] __netif_receive_skb_core+0x358/0x500 [2015-05-12 19:16:13] process_backlog+0x92/0x154 [2015-05-12 19:16:13] net_rx_action+0xb8/0x188 [2015-05-12 19:16:13] __do_softirq+0xda/0x1d8 [2015-05-12 19:16:14] irq_exit+0x8a/0x8c [2015-05-12 19:16:14] arch_do_IRQ+0x6c/0xa8 [2015-05-12 19:16:14] handle_interrupt_level1+0xe4/0xf0 Signed-off-by: NNoam Camus <noamc@ezchip.com> Acked-by: NPeter Zijlstra <peterz@infradead.org>
-
由 Noam Camus 提交于
On ARC, lower 2G of address space is translated and used for - user vaddr space (region 0 to 5) - unused kernel-user gutter (region 6) - kernel vaddr space (region 7) where each region simply represents 256MB of address space. The kernel vaddr space of 256MB is used to implement vmalloc, modules So far this was enough, but not on EZChip system with 4K CPUs (given that per cpu mechanism uses vmalloc for allocating chunks) So allow VMALLOC_SIZE to be configurable by expanding down into the unused kernel-user gutter region which at default 256M was excessive anyways. Also use _BITUL() to fix a build error since PGDIR_SIZE cannot use "1UL" as called from assembly code in mm/tlbex.S Signed-off-by: NNoam Camus <noamc@ezchip.com> [vgupta: rewrote changelog, debugged bootup crash due to int vs. hex] Acked-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Noam Camus 提交于
UAPI header should not use Kconfig items Use __BIG_ENDIAN__ defined as a compiler intrinsic Signed-off-by: NNoam Camus <noamc@ezchip.com> [vgupta: fix changelog] Signed-off-by: NVineet Gupta <vgupta@synopsys.com> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Alexey Brodkin 提交于
There are no more users of this - so RIP! Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com> [vgupta: update changelog] Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
This will be needed for switching to linear irq domain as irq_create_mapping() called by intr code needs the IRQ numbers in addition to existing usage in mcip.c for requesting the irq Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
- timer frequency is derived from DT (no longer rely on top level DT "clock-frequency" probed early and exported by asm/clk.h) - TIMER0_IRQ need not be exported across arch code, confined to intc as it is property of same - Any failures in clockevent setup are considered pedantic and system panic()'s as there is no generic fallback (unlike clocksource where a jiffies based soft clocksource always exists) Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Noam Camus 提交于
ARC Timers so far have been handled as "legacy" w/o explicit description in DT. This poses challenge for newer platforms wanting to use them. This series will eventually help move timers over to DT. This patch does a small change of using a CPU notifier to set clockevent on non-boot CPUs. So explicit setup is done only on boot CPU (which will later be done by DT) Signed-off-by: NNoam Camus <noamc@ezchip.com> [vgupta: broken off from a bigger patch] Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
- The idea is to remove the API usage since it has a subltle design flaw - relies on being called on cpu0 first. This is true for some early per cpu irqs such as TIMER/IPI, but not for late probed per cpu peripherals such a perf. And it's usage in perf has already bitten us once: see c6317bc7 ("ARCv2: perf: Ensure perf intr gets enabled on all cores") where we ended up open coding it anyways - The seeming duplication will go away once we start using cpu notifier for timer setup Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 05 5月, 2016 4 次提交
-
-
由 Vineet Gupta 提交于
Initial HIGHMEM support on ARC was introduced for PAE40 where the low memory (0x8000_0000 based) and high memory (0x1_0000_0000) were physically contiguous. So CONFIG_FLATMEM sufficed (despite a peipheral hole in the middle, which wasted a bit of struct page memory, but things worked). However w/o PAE, highmem was not possible and we could only reach ~1.75GB of DDR. Now there is a use case to access ~4GB of DDR w/o PAE40 The idea is to have low memory at canonical 0x8000_0000 and highmem at 0 so enire 4GB address space is available for physical addressing This needs additional platform/interconnect mapping to convert the non contiguous physical addresses into linear bus adresses. From Linux point of view, non contiguous divide means FLATMEM no longer works and DISCONTIGMEM is needed to track the pfns in the 2 regions. This scheme would also work for PAE40, only better in that we don't waste struct page memory for the peripheral hole. The DT description will be something like memory { ... reg = <0x80000000 0x200000000 /* 512MB: lowmem */ 0x00000000 0x10000000>; /* 256MB: highmem */ } Signed-off-by: NNoam Camus <noamc@ezchip.com> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
So a benign looking cleanup which macro'ized PAGE_SHIFT shifts turned out to be bad (since it was done non-sensically across the board). It caused boot failures with PAE40 as forced cast to (unsigned long) from newly introduced virt_to_pfn() was causing truncatiion of the (long long) pte/paddr values. It is OK to use this in accessors dealing with kernel virtual address, pointers etc, but not for PTE values themelves. Fixes: cJ2ff5cf2735c ("ARC: mm: Use virt_to_pfn() for addr >> PAGE_SHIFT pattern) Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
While reviewing a different change to asm-generic/io.h Arnd spotted that ARC ioread32 and ioread32be both of which come from asm-generic versions are not symmetrical in terms of calling the io barriers. generic ioread32 -> ARC readl() [ has barriers] generic ioread32be -> __be32_to_cpu(__raw_readl()) [ lacks barriers] While generic ioread32be is being remediated to call readl(), that involves a swab32(), causing double swaps on ioread32be() on Big Endian systems. So provide our versions of big endian IO accessors to ensure io barrier calls while also keeping them optimal Suggested-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NArnd Bergmann <arnd@arndb.de> Cc: stable@vger.kernel.org [4.2+] Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 James Hogan 提交于
The newer renameat2 syscall provides all the functionality provided by the renameat syscall and adds flags, so future architectures won't need to include renameat. Therefore drop the renameat syscall from the generic syscall list unless __ARCH_WANT_RENAMEAT is defined by the architecture's unistd.h prior to including asm-generic/unistd.h, and adjust all architectures using the generic syscall list to define it so that no in-tree architectures are affected. Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Acked-by: NVineet Gupta <vgupta@synopsys.com> Cc: linux-arch@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Mark Salter <msalter@redhat.com> Cc: Aurelien Jacquiot <a-jacquiot@ti.com> Cc: linux-c6x-dev@linux-c6x.org Cc: Richard Kuo <rkuo@codeaurora.org> Cc: linux-hexagon@vger.kernel.org Cc: linux-metag@vger.kernel.org Cc: Jonas Bonn <jonas@southpole.se> Cc: linux@lists.openrisc.net Cc: Chen Liqin <liqin.linux@gmail.com> Cc: Lennox Wu <lennox.wu@gmail.com> Cc: Chris Metcalf <cmetcalf@mellanox.com> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: Ley Foon Tan <lftan@altera.com> Cc: nios2-dev@lists.rocketboards.org Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: uclinux-h8-devel@lists.sourceforge.jp Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 22 4月, 2016 1 次提交
-
-
由 Evgeny Voevodin 提交于
- The asm helpers for calling into irq tracer were missing - Add calls to above helpers in low level assembly entry code for ARCv2 - irq_save() uses CLRI to disable interrupts and returns the prev interrupt state (in STATUS32) in a specific encoding (and not the raw value of STATUS32). This is usable with SETI in irq_restore(). However save_flags() reads the raw value of STATUS32 which doesn't pair with irq_save/restore() and thus needs fixing. Signed-off-by: NEvgeny Voevodin <evgeny.voevodin@intel.com> [vgupta: updated changelog and also added some comments] Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 07 4月, 2016 1 次提交
-
-
由 Alexey Brodkin 提交于
During mmaping of frame-buffer pages to user-space fb_protect() is called to set proper page settings. In case of ARC we need to mark pages that are mmaped to user as uncached because of 2 reasons: * Huge amount of data if passing through data cache will thrash cache a lot making cache almost useless for other less traffic hungry processes. * Data written by user in FB will be immediately available for hardware (such as PGU etc) without requirements to flush data cache regularly. Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com> Cc: linux-snps-arc@lists.infradead.org Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 19 3月, 2016 2 次提交
-
-
由 Vineet Gupta 提交于
The peripheral address space is architectural address window which is uncached and typically used to wire up peripherals. For ARC700 cores (ARCompact ISA based) this was fixed to 1GB region 0xC000_0000 - 0xFFFF_FFFF. For ARCv2 based HS38 cores the start address is flexible and can be 0xC, 0xD, 0xE, 0xF 000_000 by programming AUX_NON_VOLATILE_LIMIT reg (typically done in bootloader) Further in cas of PAE, the physical address can extend beyond 4GB so need to confine this check, otherwise all pages beyond 4GB will be treated as uncached Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
由 Vineet Gupta 提交于
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-