Re: [Qemu-devel] [PATCH] RISC-V: Correct typo in RV32 perf counters

[Peter Maydell <peter.maydell@linaro.org>]

On 30 July 2018 at 12:42, Michael Clark <mjc@sifive.com> wrote:
>
>
> On Mon, 30 Jul 2018 at 10:46 PM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
>>
>> On 25 May 2018 at 14:17, Richard Henderson <rth@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 <rth@twiddle.net>
>> >> Signed-off-by: Michael Clark <mjc@sifive.com>
>> >> ---
>> >>  target/riscv/op_helper.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > Fixes: Coverity CID 1390849
>> > Reviewed-by: Richard Henderson <richard.henderson@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