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

ARC: clone syscall to setp r25 as thread pointer

2018-10-05T21:33:29+00:00

Per ARC TLS ABI, r25 is designated TP (thread pointer register).
However so far kernel didn't do any special treatment, like setting up
usermode r25, even for CLONE_SETTLS. We instead relied on libc runtime
to do this, in say clone libc wrapper [1]. This was deliberate to keep
kernel ABI agnostic (userspace could potentially change TP, specially
for different ARC ISA say ARCompact vs. ARCv2 with different spare
registers etc)

However userspace setting up r25, after clone syscall opens a race, if
child is not scheduled and gets a signal instead. It starts off in
userspace not in clone but in a signal handler and anything TP sepcific
there such as pthread_self() fails which showed up with uClibc
testsuite nptl/tst-kill6 [2]

Fix this by having kernel populate r25 to TP value. So this locks in
ABI, but it was not going to change anyways, and fwiw is same for both
ARCompact (arc700 core) and ARCvs (HS3x cores)

[1] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/clone.S
[2] https://github.com/wbx-github/uclibc-ng-test/blob/master/test/nptl/tst-kill6.c

Fixes: ARC STAR 9001378481
Cc: stable@vger.kernel.org
Reported-by: Nikita Sobolev 
Signed-off-by: Vineet Gupta

ARC: build: Don't set CROSS_COMPILE in arch's Makefile

2018-09-18T20:24:34+00:00

There's not much sense in doing that because if user or
his build-system didn't set CROSS_COMPILE we still may
very well make incorrect guess.

But as it turned out setting CROSS_COMPILE is not as harmless
as one may think: with recent changes that implemented automatic
discovery of __host__ gcc features unconditional setup of
CROSS_COMPILE leads to failures on execution of "make xxx_defconfig"
with absent cross-compiler, for more info see [1].

Set CROSS_COMPILE as well gets in the way if we want only to build
.dtb's (again with absent cross-compiler which is not really needed
for building .dtb's), see [2].

Note, we had to change LIBGCC assignment type from ":=" to "="
so that is is resolved on its usage, otherwise if it is resolved
at declaration time with missing CROSS_COMPILE we're getting this
error message from host GCC:

| gcc: error: unrecognized command line option -mmedium-calls
| gcc: error: unrecognized command line option -mno-sdata

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004308.html
[2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004320.html

Signed-off-by: Alexey Brodkin 
Cc: Masahiro Yamada 
Cc: Rob Herring 
Signed-off-by: Vineet Gupta

ARC: fix spelling mistake "entires" -> "entries"

2018-09-14T17:32:49+00:00

Trivial fix to spelling mistake in Kconfig

Signed-off-by: Colin Ian King 
Signed-off-by: Vineet Gupta

ARC: build: Get rid of toolchain check

2018-09-13T21:48:05+00:00

This check is very naive: we simply test if GCC invoked without
"-mcpu=XXX" has ARC700 define set. In that case we think that GCC
was built with "--with-cpu=arc700" and has libgcc built for ARC700.

Otherwise if ARC700 is not defined we think that everythng was built
for ARCv2.

But in reality our life is much more interesting.

1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
   it may generate code for any ARC core).

2. libgcc might be built with explicitly specified "--mcpu=YYY"

That's exactly what happens in case of multilibbed toolchains:
 - GCC is configured with default settings
 - All the libs built for many different CPU flavors

I.e. that check gets in the way of usage of multilibbed
toolchains. And even non-multilibbed toolchains are affected.
OpenEmbedded also builds GCC without "--with-cpu" because
each and every target component later is compiled with explicitly
set "-mcpu=ZZZ".

Acked-by: Rob Herring 
Signed-off-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta

ARCv2: build: use mcpu=hs38 iso generic mcpu=archs

2018-09-10T16:25:38+00:00

helps gcc with better instruction selections such as 64-bit multiply MPYD

before
------
82c34b58 :
82c34b58:	ld	r2,[0x83068d00]
82c34b60:	add_s	r2,r2,0x7530
82c34b66:	mov_s	r0,0x989680
82c34b6c:	mpymu	r5,r2,r0
82c34b70:	mpy	r4,r2,r0
82c34b74:	mov_s	r0,r4
82c34b76:	j_s.d	[blink]
82c34b78:	mov_s	r1,r5
82c34b7a:	nop_s

after
------
82c34b7c :
82c34b7c:	ld	r0,[0x83064d00]
82c34b84:	add_s	r0,r0,0x7530
82c34b8a:	mpydu	r0,r0,0x989680
82c34b92:	j_s	[blink]

Signed-off-by: Vineet Gupta

ARC: don't check for HIGHMEM pages in arch_dma_alloc

2018-09-04T20:21:38+00:00

__GFP_HIGHMEM flag is cleared by upper layer functions
(in include/linux/dma-mapping.h) so we'll never get a
__GFP_HIGHMEM flag in arch_dma_alloc gfp argument.
That's why alloc_pages will never return highmem page
here.

Get rid of highmem pages handling and cleanup arch_dma_alloc
and arch_dma_free functions.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Vineet Gupta

ARC: IOC: panic if both IOC and ZONE_HIGHMEM enabled

2018-09-04T20:21:37+00:00

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Vineet Gupta

ARC: dma [IOC] Enable per device io coherency

2018-09-04T20:21:37+00:00

So far the IOC treatment was global on ARC, being turned on (or off)
for all devices in the system. With this patch, this can now be done
per device using the "dma-coherent" DT property; IOW with this patch
we can use both HW-coherent and regular DMA peripherals simultaneously.

The changes involved are too many so enlisting the summary below:

1. common code calls ARC arch_setup_dma_ops() per device.

2. For coherent dma (IOC) it plugs in generic @dma_direct_ops which
   doesn't need any arch specific backend: No need for any explicit
   cache flushes or MMU mappings to provide for uncached access

   - dma_(map|sync)_single* return early as corresponding dma ops callbacks
     are NULL in generic code.
     So arch_sync_dma_*() -> dma_cache_*() need not handle the coherent
     dma case, hence drop ARC __dma_cache_*_ioc() which were no-op anyways

3. For noncoherent dma (non IOC) generic @dma_noncoherent_ops is used
   which in turns calls ARC specific routines

   - arch_dma_alloc() no longer checks for @ioc_enable since this is
     called only for !IOC case.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Vineet Gupta 
[vgupta: rewrote changelog]

ARC: dma [IOC]: mark DMA devices connected as dma-coherent

2018-08-31T19:47:26+00:00

Mark DMA devices on AXS103 and HSDK boards connected through IOC
port as dma-coherent.

Signed-off-by: Eugeniy Paltsev 
Signed-off-by: Vineet Gupta

ARC: atomics: unbork atomic_fetch_##op()

2018-08-31T17:14:51+00:00

In 4.19-rc1, Eugeniy reported weird boot and IO errors on ARC HSDK

| INFO: task syslogd:77 blocked for more than 10 seconds.
|       Not tainted 4.19.0-rc1-00007-gf213acea4e88 #40
| "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
| message.
| syslogd         D    0    77     76 0x00000000
|
| Stack Trace:
|  __switch_to+0x0/0xac
|  __schedule+0x1b2/0x730
|  io_schedule+0x5c/0xc0
|  __lock_page+0x98/0xdc
|  find_lock_entry+0x38/0x100
|  shmem_getpage_gfp.isra.3+0x82/0xbfc
|  shmem_fault+0x46/0x138
|  handle_mm_fault+0x5bc/0x924
|  do_page_fault+0x100/0x2b8
|  ret_from_exception+0x0/0x8

He bisected to 84c6591103db ("locking/atomics,
asm-generic/bitops/lock.h: Rewrite using atomic_fetch_*()")

This commit however only unmasked the real issue introduced by commit
4aef66c8ae9 ("locking/atomic, arch/arc: Fix build") which missed the
retry-if-scond-failed branch in atomic_fetch_##op() macros.

The bisected commit started using atomic_fetch_##op() macros for building
the rest of atomics.

Fixes: 4aef66c8ae9 ("locking/atomic, arch/arc: Fix build")
Reported-by: Eugeniy Paltsev 
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Will Deacon 
Signed-off-by: Vineet Gupta 
[vgupta: wrote changelog]