[PATCH v4 4/8] arm64: Add sysreg header generation scripting
Mark Brown
broonie at kernel.org
Thu Apr 21 08:46:49 PDT 2022
On Thu, Apr 21, 2022 at 04:35:14PM +0100, Mark Rutland wrote:
> On Thu, Apr 21, 2022 at 03:50:41PM +0100, Mark Brown wrote:
> > Until we need it that can just be equivalent to a comment, ready to kick
> > in once someone needs it. I can update the existing (trivial but meh)
> > TTBRn register conversion to do that.
> FWIW, I'm happy either way (i.e. TTBRn to staty as-is, or be converted),
> given the duplication is trivial.
Yes, I don't think it's particularly *useful* to do this for TTBRn, but
it does demonstrate the mechanism which can then be applied to other
more interesting registers.
> > I was talking about a completely different issue, things like CPTR_EL2
> > where the register layout changes depending on some runtime
> > configuration. You'd need two separate register layouts within a single
> > Sysreg which isn't too bad until you get to the point of having to name
> > things like RES0/RES1 and any name collisons in fields (I don't *think*
> > we have name collisons...).
> I understood that was a distinct problem; what I was suggesting is the
> same mechanism might help there, as e.g. it would allow us to do:
> # Creates CPTR_EL2__E2H1_RES0, etc
> SysregFields CPTR_EL2__E2H1
> Comment "CPTR_EL2 layout when HCR_EL2.E2H == 1"
> ...
> EndSysregFields
...
> ... or where we have two names for the same register encoding (which is
> really silly, but does exist):
Right, that'd work but it has the disadvantage that we can't then
blindly use CPTR_EL2_ZEN_MASK or whatever. That might be fine, it's a
small number of registers and could help someone spot being in the wrong
mode, but perhaps not. The alternative is to teach the script about
multiple layouts for a single register. I don't have a particularly
strong opinion there, and I think it's reasonable to punt until
converting the affected registers so people can look at concrete
suggestions and their impact on the relevant code.
> Sysreg ICV_EOIR0_EL1 3 0 12 8 1
> Comment "See ICx_EOIR0_EL1_*"
> NoFields
> EndSysreg
>
> Sysreg ICH_EOIR0_EL1 3 0 12 8 1
> Comment "See ICx_EOIR0_EL1_*"
> NoFields
> EndSysreg
>
> SysregFields ICx_EOIR0_EL1
> Comment "Shared layout for ICV_EOIR0_EL1 and ICH_EOIR0_EL1"
> Res0 63:24
> Field 23:0 INTID
> EndSysregFields
> I can believe there are problems with that, and/or maybe it's too ugly.
TBH that seems fine to me, at the level of generating the defines it's
just a shared layout.
-------------- 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/20220421/ca569072/attachment.sig>
More information about the linux-arm-kernel
mailing list