[PATCH v5 00/12] arm64: Automatic system register definition generation

[Mark Brown]

On Tue, May 03, 2022 at 12:28:50PM +0100, Catalin Marinas wrote:

> I'm not convinced that we need the RES[01]_msb_lsb definitions, I'd
> rather have a RES[01] with all the UL(x) or'ed in. We want to avoid
> anyone making use of the RES1_x explicitly, though most likely we'd
> notice this during review. But these are some 'constants' that will keep
> changing even their macro name, not just the value (when one bit from
> the field gets used for something else).

Yes, I think that's just an implementation artifact rather than a thing
that's specifically intended to be useful.

> We could indeed add signed info for the enum fields at some point. As
> for kernel possible like FTR_VISIBLE, not sure whether we should add
> them to the same sysreg file. My instinct is to keep it strictly about
> the architecture definitions, not kernel policy.

My feeling with the kernel policy/ABI stuff is that we should put that
in a separate file that references the symbols we generate here rather
than merging the kernel policy into this file - as you say they're
separate things.  If we keep the stuff that's being typed in from the
DDI0487 in it's own file it's going to be easier to cross check.  We
have enough different places where we need to type in all the kernel
specific stuff (hwcaps documentation & code, cpufeatures, user visible
CPU feature register lists & code and possibly more I don't remember off
the top of my head) that I think we should be doing something to
simplify those and make them less repetitive/redundant but it does make
sense to keep it separate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220503/544c51f1/attachment.sig>