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
