Messages in this thread | | | Date | Tue, 13 Sep 2022 12:30:01 +0100 | From | Mark Brown <> | Subject | Re: [PATCH V2 1/7] arm64/perf: Add register definitions for BRBE |
| |
On Tue, Sep 13, 2022 at 11:54:09AM +0530, Anshuman Khandual wrote: > On 9/12/22 15:27, Mark Brown wrote: > > On Thu, Sep 08, 2022 at 10:40:40AM +0530, Anshuman Khandual wrote:
> >> arch/arm64/include/asm/sysreg.h | 222 ++++++++++++++++++++++++++++++++ > >> 1 file changed, 222 insertions(+)
> > Rather than manually encoding register definitions in sysreg.h > > can we add them to arch/arm64/tools/sysreg so that all the > > #defines and so on are generated instead?
> SYS_[BRBINF<N>|BRBSRC<N>|BRBTGT<N>]_EL1 registers are encoded as per three > distinct formulas where <CRm> and <op2> are derived from corresponding <N> > Just wondering if those could be accommodated in arch/arm64/tools/sysreg ?
It'd need some work on the script but if there's a reusable pattern there (I'd guess there might be) then adding some support for generating patterns like that seems like a sensible thing.
> System register description via arch/arm64/tools/sysreg seems bit cryptic.
It's very close to the way they're definied in the ARM, and I'd say a good bit easier than typing out all the individual defines and making sure there's no typos.
> BTW, do we expect all existing sysreg definitions to move there ? Because > still there are many registers and their fields present in sysreg.h
Yes, we expect all registers to be converted. This process is onging and if you don't do it now someone will just have to go and convert it later.
> Besides, there is also some benefit in being able to grep system registers > and their fields, across headers and implementations simultaneously.
That's true. On the other hand having consistently generated defines that are tied to the architecture means that people can look at the ARM and know that there's a define already provided without having to go check, and having everything generated in a very consistent fashion means that we can write helpers which take advantage of that fact - the SYSREG_FIELD_GET() and _PREP() helpers are an example of that, once James' series for the 32 bit ID registers lands we'll be able to start adding more for the cpufeature stuff.
At the minute the major advantage is that you only have to cross check the input file with the architecture when reviewing, and that has a format that's very close to the architecture so is much easier to validate. [unhandled content-type:application/pgp-signature] | |