[PATCH v11 03/40] arm64: cpufeature: Always specify and use a field width for capabilities

[Catalin Marinas]

On Wed, Mar 02, 2022 at 10:12:09AM +0000, Marc Zyngier wrote:
> On Tue, 01 Mar 2022 22:56:41 +0000,
> Qian Cai <quic_qiancai at quicinc.com> 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 <broonie at kernel.org>
> > 
> > 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.

We should indeed have a check. Alternatively, assume the default to be 4
and convert all 0s to 4 during boot (less patch churn).

-- 
Catalin