On Thu, 21 Dec 2023, Jan Beulich wrote: > On 20.12.2023 13:15, Federico Serafini wrote: > > On 20/12/23 12:55, Jan Beulich wrote: > >> On 20.12.2023 12:48, Julien Grall wrote: > >>> On 20/12/2023 11:03, Federico Serafini wrote: > >>>> --- a/xen/arch/arm/arm64/vsysreg.c > >>>> +++ b/xen/arch/arm/arm64/vsysreg.c > >>>> @@ -210,8 +210,8 @@ void do_sysreg(struct cpu_user_regs *regs, > >>>> /* RO at EL0. RAZ/WI at EL1 */ > >>>> if ( regs_mode_is_user(regs) ) > >>>> return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, > >>>> 0); > >>>> - else > >>>> - return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1); > >>>> + > >>>> + return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1); > >>> > >>> I don't 100% like this change (mostly because I find if/else clearer > >>> here). > >> > >> While (it doesn't matter here) my view on this is different, I'm still > >> puzzled why the tool would complain / why a change here is necessary. > >> It is not _one_ return statement, but there's still (and obviously) no > >> way of falling through. > > > > The tool is configurable: > > if you prefer deviate these cases instead of refactoring the code > > I can update the configuration. > > I guess this then needs to be discussed on the first call in the new year. > Stefano - can you take note of that, please?
Yes, will do
