All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/6] arm64/sysreg: Annotate signed enumerations
Date: Fri, 9 Dec 2022 13:33:49 +0000	[thread overview]
Message-ID: <Y5M5PSdd8BmPBkbt@sirena.org.uk> (raw)
In-Reply-To: <Y5MtIskhPZGqjA1u@FVFF77S0Q05N>


[-- Attachment #1.1: Type: text/plain, Size: 1629 bytes --]

On Fri, Dec 09, 2022 at 12:42:10PM +0000, Mark Rutland wrote:
> On Thu, Dec 08, 2022 at 04:03:25PM +0000, Mark Brown wrote:

> > ID_AA64PFR0_EL1.FP and ID_AA64PFR0_EL1.AdvSIMD are both signed enumerations,
> > specify them as such in sysreg. There are other signed enumerations in the
> > registers but these are the only ones for which we currently use FTR_SIGNED,
> > others can be fixed up incrementally.

> Can we please do that in one go (either in one patch or a set of patches in
> this series)?

> I appreciate that's more work up-front, but doing that will mean that all the
> definitions are in a consistent state, which'll be far less error prone going
> forwards -- people will *definitely* forget to change the other existing
> definitions to be SIGNED if all that is hidden at the point-of-use.

I am not sure I will get round to doing all that at once in a reasonable
timeframe on what is basically a low priority background task.  I'd much
rather just leave the use of FTR_SIGNED/UNSIGNED in the C code, I only
did this because I initially did that conversion and the repetitiveness
was jumping out as obvious.

> If we do that, we may as well explicitly annotate the UNSIGNED enums (and those
> which are purely enums without a sign) at the same time. That'll indicate that
> we've reviewed each entry, and it'll make it far more obvious one must do so
> when adding new entries in future.

We could also just leave Enum as unspecified, do all the UnsignedEnums,
and leave enum as unspecified and not generating a sign constant, that
any users that care about the sign of an enum won't get an incorrect
default.

[-- 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

  reply	other threads:[~2022-12-09 13:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 16:03 [PATCH 0/6] arm64/cpufeature: Make use of sysreg helpers for hwcaps Mark Brown
2022-12-08 16:03 ` [PATCH 1/6] arm64/cpufeature: Fix field sign for DIT hwcap detection Mark Brown
2022-12-09 12:25   ` Mark Rutland
2022-12-09 13:49     ` Mark Brown
2022-12-08 16:03 ` [PATCH 2/6] arm64/sysreg: Fix errors in 32 bit enumeration values Mark Brown
2022-12-09 12:29   ` Mark Rutland
2022-12-08 16:03 ` [PATCH 3/6] arm64/sysreg: Allow enumerations to be declared as signed Mark Brown
2022-12-09 12:34   ` Mark Rutland
2022-12-09 13:55     ` Mark Brown
2022-12-08 16:03 ` [PATCH 4/6] arm64/sysreg: Annotate signed enumerations Mark Brown
2022-12-09 12:42   ` Mark Rutland
2022-12-09 13:33     ` Mark Brown [this message]
2022-12-09 16:03       ` Mark Rutland
2022-12-08 16:03 ` [PATCH 5/6] arm64/cpufeature: Always use symbolic name for feature value in hwcaps Mark Brown
2022-12-09 12:48   ` Mark Rutland
2022-12-08 16:03 ` [PATCH 6/6] arm64/cpufeature: Use helper macros to specify hwcaps Mark Brown
2022-12-09 12:51   ` Mark Rutland

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=Y5M5PSdd8BmPBkbt@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \
    --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.