[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y6B8fzaFSwmJ5VC1@sirena.org.uk>
Date: Mon, 19 Dec 2022 15:00:15 +0000
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Akihiko Odaki <akihiko.odaki@...nix.com>,
linux-kernel@...r.kernel.org, kvmarm@...ts.linux.dev,
kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Oliver Upton <oliver.upton@...ux.dev>,
Suzuki K Poulose <suzuki.poulose@....com>,
Alexandru Elisei <alexandru.elisei@....com>,
James Morse <james.morse@....com>,
Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
asahi@...ts.linux.dev, Alyssa Rosenzweig <alyssa@...enzweig.io>,
Sven Peter <sven@...npeter.dev>,
Hector Martin <marcan@...can.st>
Subject: Re: [PATCH v3 1/7] arm64/sysreg: Convert CCSIDR_EL1 to automatic
generation
On Sun, Dec 18, 2022 at 01:11:01PM +0000, Marc Zyngier wrote:
> Akihiko Odaki <akihiko.odaki@...nix.com> wrote:
> > arch/arm64/tools/gen-sysreg.awk does not allow a hole and requires all
> > bits are described hence these descriptions. If you have an
> > alternative idea I'd like to hear.
> I'd simply suggest creating an UNKNOWN field encompassing bits
> [21:28]. Alternatively, feel free to try the patch below, which allows
> you to describe these 4 bits as "Unkn 31:28", similar to Res0/Res1.
I agree, where practical we should add new field types and other
features as needed rather than trying to shoehorn things into what the
tool currently supports. It is very much a work in progress which can't
fully represent everything in the spec yet. For things like the
registers with multiple possible views it's much more effort which
shouldn't get in the way of progress on features but with something like
this just updating the tool so we can match the architecture spec is the
right thing.
> Define an 'Unkn' field type modeled after the Res0/Res1 types
> to allow such description. This allows the generation of
I'd be tempted to spell out Unknown fully since Unkn is not such a
common abbreviation but I can see the desire to keep the name shorter
and it doesn't really matter so either way:
Reviewed-by: Mark Brown <broonie@...nel.org>
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists