linux-toradex.git/arch/arc, branch v4.9.15

ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup

2017-02-14T23:25:33+00:00

commit a524c218bc94c705886a0e0fedeee45d1931da32 upstream.

Reported-by: Jo-Philipp Wich 
Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
Cc: linux-kernel@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARC: [arcompact] handle unaligned access delay slot corner case

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

commit 9aed02feae57bf7a40cb04ea0e3017cb7a998db4 upstream.

After emulating an unaligned access in delay slot of a branch, we
pretend as the delay slot never happened - so return back to actual
branch target (or next PC if branch was not taken).

Curently we did this by handling STATUS32.DE, we also need to clear the
BTA.T bit, which is disregarded when returning from original misaligned
exception, but could cause weirdness if it took the interrupt return
path (in case interrupt was acive too)

One ARC700 customer ran into this when enabling unaligned access fixup
for kernel mode accesses as well

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

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: mm: IOC: Don't enable IOC by default

2016-11-28T17:18:36+00:00

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

Merge tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc

2016-11-12T00:51:50+00:00

Pull ARC fixes from Vineet Gupta:

 - mmap handler for dma ops as generic handler no longer works for us
   [Alexey]

 - Fixes for EZChip platform [Noam]

 - Fix RTC clocksource driver build issue

 - ARC IRQ handling fixes [Yuriy]

 - Revert a recent makefile change which doesn't go well with oldish
   tools out in the wild

* tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core
  ARC: IRQ: Do not use hwirq as virq and vice versa
  ARC: [plat-eznps] set default baud for early console
  ARC: [plat-eznps] remove IPI clear from SMP operations
  Revert "ARC: build: retire old toggles"
  ARC: timer: rtc: implement read loop in "C" vs. inline asm
  ARC: change return value of userspace cmpxchg assist syscall
  arc: Implement arch-specific dma_map_ops.mmap
  ARC: [SMP] avoid overriding present cpumask
  ARC: Enable PERF_EVENTS in nSIM driven platforms

Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"

2016-11-11T16:45:08+00:00

Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].

Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.

With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.

However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then.  This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle.  Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.

I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.

This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives.  A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.

Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann 
Signed-off-by: Linus Torvalds