On 10/15/2026 10:48 AM, Philippe Mathieu-Daudé wrote: > On 15/10/26 19:42, Pierrick Bouvier wrote: >> On 10/15/2026 10:37 AM, Philippe Mathieu-Daudé wrote: >>> On 14/10/26 23:05, Pierrick Bouvier wrote: >>>> Signed-off-by: Pierrick Bouvier <[email protected]> >>>> --- >>>> target/riscv/cpu.h | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h >>>> index 8c8ffe94cd8..00650a66dcb 100644 >>>> --- a/target/riscv/cpu.h >>>> +++ b/target/riscv/cpu.h >>>> @@ -755,7 +755,7 @@ FIELD(EXT_TB_FLAGS, BIG_ENDIAN, 33, 1) >>>> #ifdef TARGET_RISCV32 >>>> #define riscv_cpu_mxl(env) ((void)(env), MXL_RV32) >>>> #else >>>> -static inline RISCVMXL riscv_cpu_mxl(CPURISCVState *env) >>>> +static inline RISCVMXL riscv_cpu_mxl(const CPURISCVState *env) >>>> { >>>> return env->misa_mxl; >>>> } >>> >>> Reviewed 6 weeks ago and in Alistair riscv-next queue IIRC: >>> https://lore.kernel.org/qemu-devel/20260901095229.72018-17- >>> [email protected]/ >>> >>> Anyway, >>> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> >>> >> >> Did you flush the rest, or is it going through all submaintainers trees? >> >> I feel that system wide series like this should be sent on their own at >> once to avoid having a state spread across multiple people with >> different latencies. > > No, Alistair queued patches I'm depending on, and I consider a > maintainer sending the "patch queued" message a lock on the > patch. I'm stuck waiting for preliminary riscv-related patches > to get merge to reduce conflict with Alistair tree. Meanwhile > my tree grows so I'm not sure anymore it is a good process, > maybe I should have posted a PR and let Alistair deal with > the rebase conflicts. We still have 10 days until the freeze > so I guess we are still in time.
As long as the patch is strictly unmodified, the sub maintainer or top maintainer (merging the PR) won't see a conflict, since it's all done using git, and not email patches. In case there is a conflict, I would say it's definitely a submaintainer's problem since their tree is the one with a local state fixing conflicts between multiple series: probably a strong hint it should have been flushed quicker. As long as they don't have to deal with conflict, by keeping an invisible "lock" on this subtree, there is no reason for the workflow to change. I understand your situation though, there is no good way to deal with a series that depends on another in flight series: either avoid this, or repeat the required patches in your own. Regards, Pierrick
