From: Mark Brown <broonie@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Joey Gouly <joey.gouly@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] arm64/sysreg: Convert HFGITR_EL2 to automatic generation
Date: Thu, 6 Apr 2023 16:25:52 +0100 [thread overview]
Message-ID: <8aeccf95-6582-495e-930c-2d6723a21b6f@sirena.org.uk> (raw)
In-Reply-To: <20230406150456.GA11802@willie-the-truck>
[-- Attachment #1.1: Type: text/plain, Size: 1795 bytes --]
On Thu, Apr 06, 2023 at 04:04:57PM +0100, Will Deacon wrote:
> On Thu, Apr 06, 2023 at 04:02:18PM +0100, Mark Brown wrote:
> > On Thu, Apr 06, 2023 at 03:46:54PM +0100, Will Deacon wrote:
> > > Can't we generate this file from the architecture xml? That would hopefully
> > > avoid typos like this and make review less tedious.
> > I agree that this seems like a sensible idea however there has
> > previously been pushback on the idea of providing tooling to do that,
> > and we would want to manually integrate the output of any such tool
> > since there are a number of cases where for legacy or usability reasons
> > we rename or combine fields. The cases where we use a Fields block to
> > cover identical ELx versions are another issue.
> > I also note that while the XML is viewable on the web AFAICT the only
> > directly downloadable version of the architecture XML available
> > externally is in PDF format which is not entirely helpful for this
> > purpose.
> Sorry, I didn't mean to automate this in the tree, just that you could
> do it locally when you generate the patch (as I suspect this must be
> tedious for you to write out by hand too!). We've had a string of typos
> in the definitions so far, and it would be nice to take steps to avoid
> that for future changes.
Yeah, normally it's not too bad (and it can be useful to make sure
you've actually looked at the entire register definition properly) but I
did just about get annoyed enough to write something locally while doing
this register. You could certainly get a good chunk of the way there,
especially for simple fields (enums would need manual naming IIRC) - if
it hadn't been for the pushback mentioned above combined with what's on
developer.arm.com I'd probably have got round to doing something
already.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Joey Gouly <joey.gouly@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] arm64/sysreg: Convert HFGITR_EL2 to automatic generation
Date: Thu, 6 Apr 2023 16:25:52 +0100 [thread overview]
Message-ID: <8aeccf95-6582-495e-930c-2d6723a21b6f@sirena.org.uk> (raw)
In-Reply-To: <20230406150456.GA11802@willie-the-truck>
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
On Thu, Apr 06, 2023 at 04:04:57PM +0100, Will Deacon wrote:
> On Thu, Apr 06, 2023 at 04:02:18PM +0100, Mark Brown wrote:
> > On Thu, Apr 06, 2023 at 03:46:54PM +0100, Will Deacon wrote:
> > > Can't we generate this file from the architecture xml? That would hopefully
> > > avoid typos like this and make review less tedious.
> > I agree that this seems like a sensible idea however there has
> > previously been pushback on the idea of providing tooling to do that,
> > and we would want to manually integrate the output of any such tool
> > since there are a number of cases where for legacy or usability reasons
> > we rename or combine fields. The cases where we use a Fields block to
> > cover identical ELx versions are another issue.
> > I also note that while the XML is viewable on the web AFAICT the only
> > directly downloadable version of the architecture XML available
> > externally is in PDF format which is not entirely helpful for this
> > purpose.
> Sorry, I didn't mean to automate this in the tree, just that you could
> do it locally when you generate the patch (as I suspect this must be
> tedious for you to write out by hand too!). We've had a string of typos
> in the definitions so far, and it would be nice to take steps to avoid
> that for future changes.
Yeah, normally it's not too bad (and it can be useful to make sure
you've actually looked at the entire register definition properly) but I
did just about get annoyed enough to write something locally while doing
this register. You could certainly get a good chunk of the way there,
especially for simple fields (enums would need manual naming IIRC) - if
it hadn't been for the pushback mentioned above combined with what's on
developer.arm.com I'd probably have got round to doing something
already.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-04-06 15:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-23 20:44 [PATCH v3 0/2] arm64/sysregs: Generate definitions fine grained traps control registers Mark Brown
2023-03-23 20:44 ` Mark Brown
2023-03-23 20:44 ` [PATCH v3 1/2] arm64/sysreg: Convert HFG[RW]TR_EL2 to automatic generation Mark Brown
2023-03-23 20:44 ` Mark Brown
2023-03-23 20:44 ` [PATCH v3 2/2] arm64/sysreg: Convert HFGITR_EL2 " Mark Brown
2023-03-23 20:44 ` Mark Brown
2023-04-06 14:46 ` Will Deacon
2023-04-06 14:46 ` Will Deacon
2023-04-06 15:02 ` Mark Brown
2023-04-06 15:02 ` Mark Brown
2023-04-06 15:04 ` Will Deacon
2023-04-06 15:04 ` Will Deacon
2023-04-06 15:25 ` Mark Brown [this message]
2023-04-06 15:25 ` Mark Brown
2023-04-06 15:51 ` [PATCH v3 0/2] arm64/sysregs: Generate definitions fine grained traps control registers Will Deacon
2023-04-06 15:51 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8aeccf95-6582-495e-930c-2d6723a21b6f@sirena.org.uk \
--to=broonie@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.