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@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@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).