[PATCH V2 1/7] arm64/perf: Add register definitions for BRBE

[Mark Brown]

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.
-------------- 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/20220913/6b24d2ef/attachment.sig>