Any patches intended for the RISC-V port should go through the maintainer tree. I have been pretty clear that I would like to run regression tests. I do not wish to pull surprises in via master. I also do not agree with this random patch approach. It's all well and good for inactive maintainers to pop up now, but we were not getting our patches reviewed. The riscv-qemu tree is actively managed and we rebase and test at release time. I don't like the idea of busted stuff getting into the tree with patch churn correcting it. In any case we disagree regards process. Please don't break any of the branches in the riscv-qemu repository. I have scripts to tag our stable branches there (we got positive feedback from Karsten on the "series"). You are adding risk to the process. Fine. You are in charge. Don't break stuff.
On Thu, Oct 18, 2018 at 1:01 PM Palmer Dabbelt <pal...@sifive.com> wrote: > On Wed, 17 Oct 2018 16:32:10 PDT (-0700), ebl...@redhat.com wrote: > > On 10/17/18 4:54 PM, Palmer Dabbelt wrote: > >> The following changes since commit > 09558375a634e17cea6cfbfec883ac2376d2dc7f: > >> > >> Merge remote-tracking branch > 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16 > 17:42:56 +0100) > >> > >> are available in the Git repository at: > >> > >> git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0 > >> > >> for you to fetch changes up to 7c28f4da20e5585dce7d575691dac5392b7c6f78: > >> > >> RISC-V: Don't add NULL bootargs to device-tree (2018-10-17 13:02:30 > -0700) > >> > >> ---------------------------------------------------------------- > >> First RISC-V Patch Set for the 3.1 Soft Freeze > >> > > > >> ---------------------------------------------------------------- > >> Michael Clark (5): > >> RISC-V: Allow setting and clearing multiple irqs > >> RISC-V: Move non-ops from op_helper to cpu_helper > >> RISC-V: Update CSR and interrupt definitions > >> RISC-V: Add missing free for plic_hart_config > >> RISC-V: Don't add NULL bootargs to device-tree > >> > > > > Isn't this just a subset of Alistair's pull request? > > https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02342.html > > Yes, but there's still on-going discussion about the PCIe patches so > they're > not really fully reviewed. I think part of the trouble here is that there > wasn't someone submitting regular QEMU pull requests so there was always a > rush > to get things in. I've volunteered to wrangle the branches and submit > weekly > pull requests (just like I do for Linux), so now there won't be any more > big > cliffs. > > We've got a lot of patches to filter through because things have been > backed up > for a bit, so I thought it'd be best to just go with something simple for > this > first week. Assuming everything gets sorted out for the PCIe patches > they'll > just go up next week -- I'm super excited for them as well :) > > > which included: > >> ---------------------------------------------------------------- > >> Alistair Francis (5): > >> hw/riscv/virt: Increase the number of interrupts > >> hw/riscv/virt: Connect the gpex PCIe > >> riscv: Enable VGA and PCIE_VGA > >> hw/riscv/sifive_u: Connect the Xilinx PCIe > >> hw/riscv/virt: Connect a VirtIO net PCIe device > >> > >> Michael Clark (5): > >> RISC-V: Allow setting and clearing multiple irqs > >> RISC-V: Move non-ops from op_helper to cpu_helper > >> RISC-V: Update CSR and interrupt definitions > >> RISC-V: Add missing free for plic_hart_config > >> RISC-V: Don't add NULL bootargs to device-tree >