Re: [XEN PATCH 5/7] xen/arm: v{cp,sys}reg: address violations of MISRA C:2012 Rule 16.3

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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