On Tue, 01 Mar 2022 22:56:41 +0000,
Qian Cai <[email protected]> wrote:
>
> On Mon, Feb 07, 2022 at 03:20:32PM +0000, Mark Brown wrote:
> > Since all the fields in the main ID registers are 4 bits wide we have up
> > until now not bothered specifying the width in the code. Since we now
> > wish to use this mechanism to enumerate features from the floating point
> > feature registers which do not follow this pattern add a width to the
> > table. This means updating all the existing table entries but makes it
> > less likely that we run into issues in future due to implicitly assuming
> > a 4 bit width.
> >
> > Signed-off-by: Mark Brown <[email protected]>
>
> Do we leave this one alone on purpose?
>
> .desc = "GIC system register CPU interface",
> .capability = ARM64_HAS_SYSREG_GIC_CPUIF,
> .type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
> .matches = has_useable_gicv3_cpuif,
> .sys_reg = SYS_ID_AA64PFR0_EL1,
> .field_pos = ID_AA64PFR0_GIC_SHIFT,
> .sign = FTR_UNSIGNED,
> .min_field_value = 1,
>
> Since width == 0, it will generate an undefined behavior.
I don't think that's on purpose, and we should definitely address
this. Maybe we should have a warning if we spot an occurrence of
.width being 0.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
