riscv-for-linus-4.16-rc4_smp_mb   RISC-V: smb_mb() fix for 4.16-rc4 This week we have a single fix: replacing smp_mb() with __smp_mb(). We were the only architecture with smp_mb() and it appears to just be clearly wrong, so I think this is a pretty safe patch for an RC.

v4.16-rc3   Linux 4.16-rc3

riscv-for-linus-4.16-rc3-riscv_cleanups   RISC-V: Cleanups for 4.16-rc3 This pull request contains a handful of small cleanups. The only functional change is that IRQs are now enabled during exception handling, which was found when some warnings triggered with `CONFIG_DEBUG_ATOMIC_SLEEP=y`. The remaining fixes should have no functional change: `sbi_save()` has been renamed to `parse_dtb()` reflect what it actually does, and a handful of unused Kconfig entries have been removed. This is based on rc1 as a break to my usual flow, as it appears I missed rc2 over the holiday. I've merged master as of Wednesday morning, af3e79d29555 ("Merge tag 'leds_for-4.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds") without any conflicts and I've given it a simple build test. If this isn't OK then feel free to drop the patch set and I'll send another against rc3 for rc4.

v4.16-rc2   Linux 4.16-rc2

v4.16-rc1   Linux 4.16-rc1

riscv-for-linus-4.16-merge_window   RISC-V changes for 4.16 This tag 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!

v4.15   Linux 4.15

riscv-for-linus-4.15-maintainers   RISC-V: We have a new mailing list and git repo! Sorry to send something essentially as late as possible (Friday after an rc9), but we managed to get a mailing list for the RISC-V Linux port. We've been using patches@groups.riscv.org for a while, but that list has some problems (it's Google Groups and it's shared over all RISC-V software projects). The new infaread.org list is much better. We just got it on Wednesday but I used it a bit on Thursday to shake out all the configuration problems and it appears to be in working order. When I updated the mailing list I noticed that the MAINTAINERS file was pointing to our github repo, but now that we have a kernel.org repo I'd like to point to that instead so I changed that as well. We'll be centralizing all RISC-V Linux related development here as that seems to be the saner way to go about it. I can understand if it's too late to get this into 4.15, but given that it's not a code change I was hoping it'd still be OK. It would be nice to have the new mailing list and git repo in the release tarballs so when people start to find bugs they'll get to the right place.

v4.6.2-riscv-a1

riscv-archive-linux-4.6.2   RISC-V Port as of 4.6.2 This archives an old version of the RISC-V port as a tag so users can explicitly refer to it.

v4.15-rc9   Linux 4.15-rc9

v4.15-rc8   Linux 4.15-rc8

riscv-for-linus-4.15-rc8_cleanups   RISC-V changes for 4.15-rc8 This contains what I hope are the last RISC-V changes to go into 4.15. I know it's a bit last minute, but I think they're all fairly small changes: * SR_* constants have been renamed to match the latest ISA specification. * Some CONFIG_MMU #ifdef cruft has been removed. We've never supported !CONFIG_MMU. * __NR_riscv_flush_icache is now visible to userspace. We were hoping to avoid making this public in order to force userspace to call the vDSO entry, but it looks like QEMU's user-mode emulation doesn't want to emulate a vDSO. In order to allow glibc to fall back to a system call when the vDSO entry doesn't exist we're just * Our defconfig is no long empty. This is another one that just slipped through the cracks. The defconfig isn't perfect, but it's at least close to what users will want for the first RISC-V development board. Getting closer is kind of splitting hairs here: none of the RISC-V specific drivers are in yet, so it's not like things will boot out of the box. The only one that's strictly necessary is the __NR_riscv_flush_icache change, as I want that to be part of the public API starting from our first kernel so nobody has to worry about it. The others are nice to haves, but they seem sane for 4.15 to me.

v4.15-rc7   Linux 4.15-rc7

v4.15-rc6   Linux 4.15-rc6

v4.15-rc5   Linux 4.15-rc5

v4.15-rc4   Linux 4.15-rc4

riscv-for-linus-4.15-rc4-riscv_fixes   RISC-V Fixes for 4.15-rc4 This pull request contains three small fixes that I'm hoping to get into 4.15-rc4: * A fix to a typo in sys_riscv_flush_icache. This only effects error handling, but I think it's a small and obvious enough change that it's sane outside the merge window. * The addition of smp_mb__after_spinlock(), which was recently removed due to an incorrect comment. This is largly a comment change (as there's a big one now), and while it's necessary for complience with the RISC-V memory model the lack of this fence shouldn't manifest as a bug on current implementations. Nonetheless, it still seems saner to have the fence in 4.15. * The removal of some of the HVC_RISCV_SBI driver that snuck into the arch port. This is compile-time dead code in 4.15 (as the driver isn't in yet), and during the review process we found a better way to implement early printk on RISC-V. While this change doesn't do anything, it will make staging our HVC driver easier: without this change the HVC driver we hope to upstream won't build on 4.15 (because the 4.15 arch code would reference a function that no longer exists). Additionally, I'm instituting a bit of a process change so I don't submit things too quickly again: * All the patches I submit during an RC will be from the week before, so everyone has gotten a chance to see them and they've made it through our autobuilders and integration trees. * I'll cherry-pick (single patches) or merge (if it's a patch set) on top of the new RC on Monday morning. * I'll sign the tag on Monday morning, to let the autobuilders pick up exactly what I'm submitting. * Assuming nothing goes wrong, I'll mail the pull request out on Wednesday. If something goes wrong, I'll wait at least a day after re-spinning the tag to let the autobuilders pick things up. Hopefully this will avoid any headaches in the future, barring any emergency fixes. I don't think this is the last patch set we'll want for 4.15: I think I'll want to remove some of the first-level irqchip driver that snuck in as well, which will look a lot like the HVC patch here. This is pending some asm-generic cleanup I'm doing that I haven't quite gotten clean enough to send out yet, though, but hopefully it'll be ready by next week (and still OK for that late).

v4.15-rc3   Linux 4.15-rc3

v4.15-rc2   Linux 4.15-rc2