<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/riscv, branch linux-4.16.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.16.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.16.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-06-20T19:01:25+00:00</updated>
<entry>
<title>RISC-V: build vdso-dummy.o with -no-pie</title>
<updated>2018-06-20T19:01:25+00:00</updated>
<author>
<name>Aurelien Jarno</name>
<email>aurelien@aurel32.net</email>
</author>
<published>2018-03-21T21:26:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=313890fc5e8548d34bcc78736a5d8c4512e39d4b'/>
<id>urn:sha1:313890fc5e8548d34bcc78736a5d8c4512e39d4b</id>
<content type='text'>
[ Upstream commit 85602bea297fc4e5223adbf7006dcce9aa694f17 ]

Debian toolcahin defaults to PIE, and I guess that will also be the case
of most distributions. This causes the following build failure:

  AS      arch/riscv/kernel/vdso/getcpu.o
  AS      arch/riscv/kernel/vdso/flush_icache.o
  VDSOLD  arch/riscv/kernel/vdso/vdso.so.dbg
  OBJCOPY arch/riscv/kernel/vdso/vdso.so
  AS      arch/riscv/kernel/vdso/vdso.o
  VDSOLD  arch/riscv/kernel/vdso/vdso-dummy.o
  LD      arch/riscv/kernel/vdso/vdso-syms.o
riscv64-linux-gnu-ld: attempted static link of dynamic object `arch/riscv/kernel/vdso/vdso-dummy.o'
make[2]: *** [arch/riscv/kernel/vdso/Makefile:43: arch/riscv/kernel/vdso/vdso-syms.o] Error 1
make[1]: *** [scripts/Makefile.build:575: arch/riscv/kernel/vdso] Error 2
make: *** [Makefile:1018: arch/riscv/kernel] Error 2

While the root Makefile correctly passes "-fno-PIE" to build individual
object files, the RISC-V kernel also builds vdso-dummy.o as an
executable, which is therefore linked as PIE. Fix that by updating this
specific link rule to also include "-no-pie".

Signed-off-by: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>riscv: select DMA_DIRECT_OPS instead of redefining it</title>
<updated>2018-06-20T19:01:24+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2018-04-16T12:53:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=827c90886d907cf78d68f66a6397c7beaf02d007'/>
<id>urn:sha1:827c90886d907cf78d68f66a6397c7beaf02d007</id>
<content type='text'>
[ Upstream commit 86e11757d8b28d8266065beaa9d391d49426797b ]

DMA_DIRECT_OPS is defined in lib/Kconfig, so don't duplicate it in
arch/riscv/Kconfig.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>riscv/spinlock: Strengthen implementations with fences</title>
<updated>2018-05-30T06:17:24+00:00</updated>
<author>
<name>Andrea Parri</name>
<email>parri.andrea@gmail.com</email>
</author>
<published>2018-03-09T12:13:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f0d098569a0ab4ec3c2f59ef2827d46e798ce789'/>
<id>urn:sha1:f0d098569a0ab4ec3c2f59ef2827d46e798ce789</id>
<content type='text'>
[ Upstream commit 0123f4d76ca63b7b895f40089be0ce4809e392d8 ]

Current implementations map locking operations using .rl and .aq
annotations.  However, this mapping is unsound w.r.t. the kernel
memory consistency model (LKMM) [1]:

Referring to the "unlock-lock-read-ordering" test reported below,
Daniel wrote:

  "I think an RCpc interpretation of .aq and .rl would in fact
   allow the two normal loads in P1 to be reordered [...]

   The intuition would be that the amoswap.w.aq can forward from
   the amoswap.w.rl while that's still in the store buffer, and
   then the lw x3,0(x4) can also perform while the amoswap.w.rl
   is still in the store buffer, all before the l1 x1,0(x2)
   executes.  That's not forbidden unless the amoswaps are RCsc,
   unless I'm missing something.

   Likewise even if the unlock()/lock() is between two stores.
   A control dependency might originate from the load part of
   the amoswap.w.aq, but there still would have to be something
   to ensure that this load part in fact performs after the store
   part of the amoswap.w.rl performs globally, and that's not
   automatic under RCpc."

Simulation of the RISC-V memory consistency model confirmed this
expectation.

In order to "synchronize" LKMM and RISC-V's implementation, this
commit strengthens the implementations of the locking operations
by replacing .rl and .aq with the use of ("lightweigth") fences,
resp., "fence rw,  w" and "fence r , rw".

C unlock-lock-read-ordering

{}
/* s initially owned by P1 */

P0(int *x, int *y)
{
        WRITE_ONCE(*x, 1);
        smp_wmb();
        WRITE_ONCE(*y, 1);
}

P1(int *x, int *y, spinlock_t *s)
{
        int r0;
        int r1;

        r0 = READ_ONCE(*y);
        spin_unlock(s);
        spin_lock(s);
        r1 = READ_ONCE(*x);
}

exists (1:r0=1 /\ 1:r1=0)

[1] https://marc.info/?l=linux-kernel&amp;m=151930201102853&amp;w=2
    https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/hKywNHBkAXM
    https://marc.info/?l=linux-kernel&amp;m=151633436614259&amp;w=2

Signed-off-by: Andrea Parri &lt;parri.andrea@gmail.com&gt;
Cc: Palmer Dabbelt &lt;palmer@sifive.com&gt;
Cc: Albert Ou &lt;albert@sifive.com&gt;
Cc: Daniel Lustig &lt;dlustig@nvidia.com&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Boqun Feng &lt;boqun.feng@gmail.com&gt;
Cc: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Jade Alglave &lt;j.alglave@ucl.ac.uk&gt;
Cc: Luc Maranget &lt;luc.maranget@inria.fr&gt;
Cc: "Paul E. McKenney" &lt;paulmck@linux.vnet.ibm.com&gt;
Cc: Akira Yokosawa &lt;akiyks@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: linux-riscv@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>riscv/barrier: Define __smp_{mb,rmb,wmb}</title>
<updated>2018-02-26T16:44:50+00:00</updated>
<author>
<name>Andrea Parri</name>
<email>parri.andrea@gmail.com</email>
</author>
<published>2018-02-20T10:17:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ab4af60534107c55b00fa462eca0385dcef92384'/>
<id>urn:sha1:ab4af60534107c55b00fa462eca0385dcef92384</id>
<content type='text'>
Introduce __smp_{mb,rmb,wmb}, and rely on the generic definitions
for smp_{mb,rmb,wmb}. A first consequence is that smp_{mb,rmb,wmb}
map to a compiler barrier on !SMP (while their definition remains
unchanged on SMP). As a further consequence, smp_load_acquire and
smp_store_release have "fence rw,rw" instead of "fence iorw,iorw".

Signed-off-by: Andrea Parri &lt;parri.andrea@gmail.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
</content>
</entry>
<entry>
<title>Rename sbi_save to parse_dtb to improve code readability</title>
<updated>2018-02-20T18:56:26+00:00</updated>
<author>
<name>Michael Clark</name>
<email>michaeljclark@mac.com</email>
</author>
<published>2018-02-15T20:30:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8b08f50152ff85a4780e5c385d2b65889406e842'/>
<id>urn:sha1:8b08f50152ff85a4780e5c385d2b65889406e842</id>
<content type='text'>
The sbi_ prefix would seem to indicate an SBI interface, and save is not
very specific. After applying this patch, reading head.S makes more sense.

Signed-off-by: Michael Clark &lt;michaeljclark@mac.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
</content>
</entry>
<entry>
<title>RISC-V: Enable IRQ during exception handling</title>
<updated>2018-02-20T18:56:14+00:00</updated>
<author>
<name>zongbox@gmail.com</name>
<email>zongbox@gmail.com</email>
</author>
<published>2018-01-30T07:51:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bcae803a213172c79ab5d077f169e3428e44d2ba'/>
<id>urn:sha1:bcae803a213172c79ab5d077f169e3428e44d2ba</id>
<content type='text'>
Interrupt is allowed during exception handling.
There are warning messages if the kernel enables the configuration
'CONFIG_DEBUG_ATOMIC_SLEEP=y'.

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:23
in_atomic(): 0, irqs_disabled(): 1, pid: 43, name: ash
CPU: 0 PID: 43 Comm: ash Tainted:  G	 W	 4.15.0-rc8-00089-g89ffdae-dirty #17
Call Trace:
[&lt;000000009abb1587&gt;] walk_stackframe+0x0/0x7a
[&lt;00000000d4f3d088&gt;] ___might_sleep+0x102/0x11a
[&lt;00000000b1fd792a&gt;] down_read+0x18/0x28
[&lt;000000000289ec01&gt;] do_page_fault+0x86/0x2f6
[&lt;00000000012441f6&gt;] _do_fork+0x1b4/0x1e0
[&lt;00000000f46c3e3b&gt;] ret_from_syscall+0xa/0xe

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Zong Li &lt;zong@andestech.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@dabbelt.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
</content>
</entry>
<entry>
<title>riscv: Remove ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select</title>
<updated>2018-02-20T18:51:07+00:00</updated>
<author>
<name>Ulf Magnusson</name>
<email>ulfalizer@gmail.com</email>
</author>
<published>2018-02-05T01:21:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=89a4b4441206962d1bbb62f128604a269b60933d'/>
<id>urn:sha1:89a4b4441206962d1bbb62f128604a269b60933d</id>
<content type='text'>
The ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE symbol was removed in
commit 51a021244b9d ("atomic64: no need for
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE").

Remove the ARCH_HAS_ATOMIC64_DEC_IS_POSITIVE select from RISCV.

Discovered with the
https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
script.

Signed-off-by: Ulf Magnusson &lt;ulfalizer@gmail.com&gt;
Reviewed-by: Jonathan Neuschäfer &lt;j.neuschaefer@gmx.net&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
</content>
</entry>
<entry>
<title>riscv: kconfig: Remove RISCV_IRQ_INTC select</title>
<updated>2018-02-20T18:51:07+00:00</updated>
<author>
<name>Ulf Magnusson</name>
<email>ulfalizer@gmail.com</email>
</author>
<published>2018-02-08T22:54:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2aaa2dc31bee808703c24ce626e50d1b6d8c7f9c'/>
<id>urn:sha1:2aaa2dc31bee808703c24ce626e50d1b6d8c7f9c</id>
<content type='text'>
The RISCV_IRQ_INTC configuration symbol is undefined, but RISCV selects
it. Quoting Palmer Dabbelt:

	It looks like this slipped through, the symbol has been renamed
	RISCV_INTC.

No RISCV_INTC configuration symbol has been merged either. Just remove
the RISCV_IRQ_INTC select for now.

Signed-off-by: Ulf Magnusson &lt;ulfalizer@gmail.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
</content>
</entry>
<entry>
<title>riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB select</title>
<updated>2018-02-20T18:51:04+00:00</updated>
<author>
<name>Ulf Magnusson</name>
<email>ulfalizer@gmail.com</email>
</author>
<published>2018-02-05T01:21:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ab0dc41b7324329af1c18580b0fc891922a717cf'/>
<id>urn:sha1:ab0dc41b7324329af1c18580b0fc891922a717cf</id>
<content type='text'>
The ARCH_WANT_OPTIONAL_GPIOLIB symbol was removed in commit 65053e1a7743
("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB"). GPIOLIB should
just be selected explicitly if needed.

Remove the ARCH_WANT_OPTIONAL_GPIOLIB select from RISCV.

See commit 0145071b3314 ("x86: Do away with
ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") and commit da9a1c6767 ("arm64: do
away with ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") as well.

Discovered with the
https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
script.

Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Ulf Magnusson &lt;ulfalizer@gmail.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@dabbelt.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'riscv-for-linus-4.16-merge_window' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux</title>
<updated>2018-02-07T19:33:08+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-02-07T19:33:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=413879a10b0b0eb563a23c4df896773b2d9413f9'/>
<id>urn:sha1:413879a10b0b0eb563a23c4df896773b2d9413f9</id>
<content type='text'>
Pull RISC-V updates from Palmer Dabbelt:
 "This contains the fixes we'd like to target for the 4.16 merge window.
  It's not as much as I was originally hoping to do but between glibc,
  the chip, and FOSDEM there just wasn't enough time to get everything
  put together. As such, this merge window is essentially just going to
  be small changes. This includes mostly cleanups:

   - A build fix failure to the audit test cases.

     RISC-V doesn't have renameat because the generic syscall ABI moved
     to renameat2 by the time of our port. The syscall audit test cases
     don't understand this, so I added a trivial fix. This went through
     mailing list review during the 4.15 merge window, but nobody has
     picked it up so I think it's best to just do this here.

   - The removal of our command-line argument processing code. The
     "mem_end" stuff was broken and the rest duplicated generic device
     tree code. The generic code was already being called.

   - Some unused/redundant code has been removed, including
     __ARCH_HAVE_MMU, current_pgdir, and the initialization of
     init_mm.pgd.

   - SUM is disabled upon taking a trap, which means that user memory is
     protected during traps taking inside copy_{to,from}_user().

   - The sptbr CSR has been renamed to satp in C code. We haven't
     changed the assembly code in order to maintain compatibility with
     binutils 2.29, which doesn't understand the new name.

  Additionally, we're adding some new features:

   - Basic ftrace support, thanks to Alan Kao!

   - Support for ZONE_DMA32.

     This is necessary for all the normal reasons, but also to deal with
     a deficiency in the Xilinx PCIe controller we're using on our
     FPGA-based systems. While the ZONE_DMA32 addition should be
     sufficient for most uses, it doesn't complete the fix for the
     Xilinx controller.

   - TLB shootdowns now only target the harts where they're necessary,
     instead of applying to all harts in the system.

  These patches have all been sitting on our linux-next branch for a
  while now. Due to time constraints this is all I feel comfortable
  submitting during the 4.16 merge window, hopefully we'll do better
  next time!"

[ Note to self: "harts" is RISC-V speak for "hardware threads".  I had
  to look that up.    - Linus ]

* tag 'riscv-for-linus-4.16-merge_window' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux:
  riscv: inline set_pgdir into its only caller
  riscv: rename sptbr to satp
  riscv: don't read back satp in paging_init
  riscv: remove the unused current_pgdir function
  riscv: add ZONE_DMA32
  RISC-V: Limit the scope of TLB shootdowns
  riscv: disable SUM in the exception handler
  riscv: remove redundant unlikely()
  riscv: remove unused __ARCH_HAVE_MMU define
  riscv/ftrace: Add basic support
  RISC-V: Remove mem_end command line processing
  RISC-V: Remove duplicate command-line parsing logic
  audit: Avoid build failures on systems without renameat
</content>
</entry>
</feed>
