On 08/03/2018 12:18, Michael Clark wrote: >> There are multiple sign-offs in all >> 23 commits. The tag is riscv-qemu-upstream-v8.2
Except your cover letter lists 45 commits and, as Daniel has already confirmed, Peter is right: these commits listed in the cover letter have no sign-off and have not been reviewed: RISC-V - Make virt create_fdt interface consistent with other boards RISC-V - Replace hardcoded device-tree constants with enum values RISC-V - Make virt board description match spike format RISC-V - Use ROM base address and size constants from memory map RISC-V - Remove redundant identity_translate callback from load_elf RISC-V - Mark ROM read-only after copying in reset vector and config RISC-V - Remove unused class definitions from machines RISC-V - Make sure the emulated mask rom has space for device-tree RISC-V - Include hexidecimal instruction packets in disassembly RISC-V - Need to hold rcu_read_lock when accessing memory directly RISC-V - Improve page table walker spec compliance and add comments RISC-V - Update E order and note that add E and I are mutually exclusive RISC-V - Make spike and virt header guards more specific RISC-V - Make virt header comment consistent with source file RISC-V - Use memory_region_is_ram in atomic pte update RISC-V - Remove EM_RISCV ELF_MACHINE indirection from load_elf RISC-V - Ingore satp writes and return 0 for reads when no-mmu RISC-V - Remove braces from satp case statement with no locals RISC-V - riscv-qemu port supports sv39 and sv48 RISC-V - vectored traps for asynchrounous interrupts are optional RISC-V - Dont' trap on writes to misa,minstret[h],mcycle[h] RISC-V - Remove support for adhoc non-standard X_COP local-interrupt > You are making this very hard. Do you work for Arm perchance? I really > wouldn’t be surprised if our port is being sandbagged by Arm. Apologies for > being so direct about this, but things like this happen... > > I have complied with practically every review request and the sign-offs are > there. It’s a bit ridiculous. > > It would be nice to find someone neutral, unrelated to Arm, to merge our PR Just don't do this. If you don't trust the maintainers, I don't see why the maintainers should merge the RISC-V port; no one needs an history lesson on RISC or ARM or RISC-V either. And you can understand that adding and reviewing 10K lines of code requires a significant effort, that some of the maintainers are doing in their spare time. In fact, I looked at "RISC-V - Need to hold rcu_read_lock when accessing memory directly" and from a first look it's wrong. So I think you owe an apology... Paolo