On 15/10/26 20:09, Pierrick Bouvier wrote:
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.
Fundamentals of git indeed. I'll try, hoping that improve the pace we
get series merge, hoping it won't disturb Alistair tree.
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
