On 30 July 2018 at 12:42, Michael Clark <m...@sifive.com> wrote: > > > On Mon, 30 Jul 2018 at 10:46 PM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> >> On 25 May 2018 at 14:17, Richard Henderson <r...@twiddle.net> wrote: >> > On 05/24/2018 11:24 PM, Michael Clark wrote: >> >> This patch enables mhpmcounter3h through mhpmcounter31h on RV32. >> >> Previously the RV32 h versions (high 32-bits of 64-bit counters) >> >> of these counters would trap with an illegal instruction instead >> >> of returning 0 as intended. >> >> >> >> Reported-by: Richard Henderson <r...@twiddle.net> >> >> Signed-off-by: Michael Clark <m...@sifive.com> >> >> --- >> >> target/riscv/op_helper.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > Fixes: Coverity CID 1390849 >> > Reviewed-by: Richard Henderson <richard.hender...@linaro.org> >> >> Ping -- Coverity is still complaining about this -- did this >> patch get lost? > > > Sort of. I assumed it would go into a trivial queue.
As a general rule of thumb, patches which apply to an area of code which has a maintainer (especially when that area is in active development, as riscv is), usually go through that maintainer's tree. Picking up and shepherding patches like this into master is one of the things maintainers do in QEMU's system. The -trivial queue mostly exists for things which would otherwise fall through the cracks between different subsystems. > Feel free to apply, however it’s going to create (another) rebase conflict > against my ‘for-upstream’ queue as this code has gone away, hence it is not > in my queue. That sort of possibility for conflicts is why it makes more sense to put even fairly minor patches through maintainer trees rather than via -trivial). > I can include this change in my pull for 3.1, along with the patches in my > tree that have Reviewed-by and fix the rebase conflicts for anything that > depends on new context (hopefully not creating new bugs during that > process). If the code has been removed then you don't need to put this patch in your pullrequest for 3.1, because you already have changes that make it moot. (Given that Coverity spotted it rather than an actual user it doesn't seem like a bug fix urgent enough to put in 3.0.) thanks -- PMM
