linux-toradex.git/arch/arc/include, branch v4.9.14

ARC: udelay: fix inline assembler by adding LP_COUNT to clobber list

2017-02-01T07:33:08+00:00

commit 36425cd67052e3becf325fd4d3ba5691791ef7e4 upstream.

commit 3c7c7a2fc8811bc ("ARC: Don't use "+l" inline asm constraint")
modified the inline assembly to setup LP_COUNT register manually and NOT
rely on gcc to do it (with the +l inline assembler contraint hint, now
being retired in the compiler)

However the fix was flawed as we didn't add LP_COUNT to asm clobber list,
meaning gcc doesn't know that LP_COUNT or zero-delay-loops are in action
in the inline asm.

This resulted in some fun - as nested ZOL loops were being generared

| mov lp_count,250000 ;16 # tmp235,
| lp .L__GCC__LP14 #		<======= OUTER LOOP (gcc generated)
|   .L14:
|   ld r2, [r5] # MEM[(volatile u32 *)prephitmp_43], w
|   dmb 1
|   breq r2, -1, @.L21 #, w,,
|   bbit0 r2,1,@.L13 # w,,
|   ld r4,[r7] ;25 # loops_per_jiffy, loops_per_jiffy
|   mpymu r3,r4,r6 #, loops_per_jiffy, tmp234
|
|   mov lp_count, r3 #		 <====== INNER LOOP (from inline asm)
|   lp 1f
| 	 nop
|   1:
|   nop_s
| .L__GCC__LP14: ; loop end, start is @.L14 #,

This caused issues with drivers relying on sane behaviour of udelay
friends.

With LP_COUNT added to clobber list, gcc doesn't generate the outer
loop in say above case.

Addresses STAR 9001146134

Reported-by: Joao Pinto 
Fixes: 3c7c7a2fc8811bc ("ARC: Don't use "+l" inline asm constraint")
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: module: Fix !CONFIG_ARC_DW2_UNWIND builds

2017-01-26T07:24:37+00:00

commit eb1357d942e5d96de6b4c20a8ffa55acf96233a2 upstream.

commit d65283f7b695b5 added mod->arch.secstr under
CONFIG_ARC_DW2_UNWIND, but used it unconditionally which broke builds
when the option was disabled. Fix that by adjusting the #ifdef guard.

And while at it add a missing guard (for unwinder) in module.c as well

Reported-by: Waldemar Brodkorb 
Fixes: d65283f7b695b5 ("ARC: module: elide loop to save reference to .eh_frame")
Tested-by: Anton Kolesov 
Reviewed-by: Alexey Brodkin 
[abrodkin: provided fixlet to Kconfig per failure in allnoconfig build]
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache

2017-01-09T07:32:21+00:00

commit 08fe007968b2b45e831daf74899f79a54d73f773 upstream.

An ARC700 customer reported linux boot crashes when upgrading to bigger
L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and
current code only assumed 2 colours, while theirs had 4. So default to 4
colours and complain if there are fewer. Ideally this needs to be a
Kconfig option, but heck that's too much of hassle for a single user.

Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: mm: PAE40: Fix crash at munmap

2016-11-29T17:12:08+00:00

commit 1c3c90930392 broke PAE40. Macro pfn_pte(pfn, prot) creates paddr
from pfn, but the page shift was getting truncated to 32 bits since we lost
the proper cast to 64 bits (for PAE400

Instead of reverting that commit, use a better helper which is 32/64 bits
safe just like ARM implementation.

Fixes: 1c3c90930392 ("ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS")
Cc:    #4.4+
Signed-off-by: Yuriy Kolerov 
[vgupta: massaged changelog]
Signed-off-by: Vineet Gupta

ARC: Don't use "+l" inline asm constraint

2016-11-28T17:17:32+00:00

Apparenty this is coming in the way of gcc fix which inhibits the usage
of LP_COUNT as a gpr.

Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta

ARC: IRQ: Do not use hwirq as virq and vice versa

2016-11-08T20:05:10+00:00

This came up when reviewing code to address missing IRQ affinity
setting in AXS103 platform and/or implementing hierarchical IRQ domains

- smp_ipi_irq_setup() callers pass hwirq but in turn calls
  request_percpu_irq() which expects a linux virq. So invoke
  irq_find_mapping() to do the conversion
  (also explicitify this in code by renaming the args appropriately)

- idu_of_init()/idu_cascade_isr() were similarly using linux virq where
  hwirq is expected, so do the conversion using irqd_to_hwirq() helper

Signed-off-by: Yuriy Kolerov 
[vgupta: made changelog a bit concise a bit]
Signed-off-by: Vineet Gupta

ARC: change return value of userspace cmpxchg assist syscall

2016-11-07T19:01:12+00:00

The original syscall only used to return errno to indicate if cmpxchg
succeeded. It was not returning the "previous" value which typical cmpxchg
callers are interested in to build their slowpaths or retry loops.
Given user preemption in syscall return path etc, it is not wise to
check this in userspace afterwards, but should be what kernel actually
observed in the syscall.

So change the syscall interface to always return the previous value and
additionally set Z flag to indicate whether operation succeeded or not
(just like ARM implementation when they used to have this syscall)
The flag approach avoids having to put_user errno which is nice given
the use case for this syscall cares mostly about the "previous" value.

Signed-off-by: Vineet Gupta

ARC: module: elide loop to save reference to .eh_frame

2016-10-28T17:10:28+00:00

The loop was really needed in .debug_frame regime where wanted make it
as SH_ALLOC so that apply_relocate_add() would process it. That's not
needed for .eh_frame, so we check this in apply_relocate_add() which
gets called for each section.

Note that we need to save reference to "section name strings" section in
module_frob_arch_sections() since apply_relocate_add() doesn't get that

Signed-off-by: Vineet Gupta

ARC: boot log: refactor cpu name/release printing

2016-10-28T17:09:07+00:00

The motivation is to identify ARC750 vs. ARC770 (we currently print
generic "ARC700").

A given ARC700 release could be 750 or 770, with same ARCNUM (or family
identifier which is unfortunate). The existing arc_cpu_tbl[] kept a single
concatenated string for core name and release which thus doesn't work
for 750 vs. 770 identification.

So split this into 2 tables, one with core names and other with release.
And while we are at it, get rid of the range checking for family numbers.
We just document the known to exist cores running Linux and ditch
others.

With this in place, we add detection of ARC750 which is
 - cores 0x33 and before
 - cores 0x34 and later with MMUv2

Signed-off-by: Vineet Gupta

ARC: boot log: don't assume SWAPE instruction support

2016-10-28T17:09:06+00:00

This came to light when helping a customer with oldish ARC750 core who
were getting instruction errors because of lack of SWAPE but boot log
was incorrectly printing it as being present

Signed-off-by: Vineet Gupta