[PATCH v4 4/8] arm64: Add sysreg header generation scripting

[Mark Brown]

On Thu, Apr 21, 2022 at 03:16:52PM +0100, Mark Rutland wrote:
> On Thu, Apr 21, 2022 at 02:00:17PM +0100, Mark Brown wrote:

> > > > The script requires that all bits in the register be specified and that
> > > > there be no overlapping fields. This helps the script spot errors in the
> > > > input but means that the few registers which change layout at runtime
> > > > depending on things like virtualisation settings will need some manual
> > > > handling. No actual register conversions are done here but a header for
> > > > the register data with some documention of the format is provided.

> > > It would be good to see an example of how we'd handle one of those, in case
> > > that means we need to play around with naming or structure of the definitions a
> > > bit.

> > My thinking here was that we might not want to handle those registers
> > through the automated stuff at all.  I haven't yet come up with
> > something that seems tasteful and viable for them, if I had a firm idea
> > for what that should look like I'd probably have implemented it.

> Sure, and I'm not expecting that we automate all of that, just that we
> have an idea of how the manual bits would work with the automatic bits.
> If the odd cases looks simple enough, we might be able to get away with
> a couple of small additions to the scripting.

> For example, for ESR_EL{1,2,3} today we define ESR_ELx_field
> definitions rather than duplicate ESR_EL1_field / ESR_EL2_field /
> ESR_EL3_field definitions. If the scripting has a mechanism to handle
> that, then that might be good enough for the other odd cases.

Ah, that's a separate issue to the registers which change layout which
was what was being mentioned above.

> For example, I think we could do something like:

> # Define a set of fields without a specific register encoding, using the
> # name `ESR_ELx`
> SysregFields	ESR_ELx
> 	Res0	63:37
> 	Field	36:32	ISS2
> 	Field	31:26	EC
> 	Field	25	IL
> 	Field	24:0	ISS
> EndSysregFields

Yes, I'd been thinking of something like this - it seemed an obvious
enough extension.

> # This could instead be SysregEncoding
> Sysreg	ESR_EL1		3	0	5	2	0
> 	Comment		"See ESR_ELx for fields"
> 	# Don't create any field definitions for this reg, and don't
> 	# bother with the associated sanity checks
> 	NoFields	
> EndSysreg

I think we're going to end up wanting to still generate the numbered
versions for use in macros so we should probably have that comment and
NoFields be a SharedLayout (or whatever bikeshedded name) statement.
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.

> ... and the `SysregFields` `NoFields`, and `Comment` mechanisms might be
> good enough to cover the other odd cases we have (e.g. aliased
> GIC registers, or different "views" for the same register).

> Does that make sense, or have I misunderstood the point you were making?

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...).
-------------- 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/4af68da1/attachment.sig>