From: Mark Brown <broonie@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Eric Biederman <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/4] arm64: Add AT_HWCAP3
Date: Wed, 6 Jul 2022 14:48:23 +0100 [thread overview]
Message-ID: <YsWSpxUkUSGOjG4b@sirena.org.uk> (raw)
In-Reply-To: <933dd93bedf07883a62f59805dc28ca9@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]
On Wed, Jul 06, 2022 at 11:08:55AM +0100, Marc Zyngier wrote:
> On 2022-07-05 18:53, Mark Brown wrote:
> > else said anything. I don't have strong preferences either way but
> > wonder if it's worth defining AT_HWCAP3 even if we start allocating more
> > bits from AT_HWCAP2 so that it's got more time to percolate through
> > libcs and so on before it's actually needed.
> I really don't like the idea of adding a new HWCAP when we still
> have free bits lying around. We should use that first, and only
> add HWCAP3 once we are at (or close enough to) the limit.
It depends what you define as close of course - it's only taken us 4
years to fill the low 32 bits in AT_HWCAP2, that doesn't make it a
pressing issue in terms of kernel development but in terms of things
like entrprise distros it's starting to get into the timescales where it
might be relevant.
[-- 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
prev parent reply other threads:[~2022-07-06 13:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 12:54 [PATCH v2 0/4] arm64: Add AT_HWCAP3 Mark Brown
2022-06-20 12:54 ` [PATCH v2 1/4] arm64/cpufeature: Store elf_hwcaps as an array rather than unsigned long Mark Brown
2022-06-28 14:21 ` Will Deacon
2022-06-28 15:06 ` Mark Brown
2022-06-29 10:01 ` Szabolcs Nagy
2022-06-29 11:44 ` Mark Brown
2022-06-29 12:06 ` Szabolcs Nagy
2022-06-29 13:55 ` Catalin Marinas
2022-06-29 15:07 ` Mark Brown
2022-06-20 12:54 ` [PATCH v2 2/4] elf: Allow architectures to provide AT_HWCAP3 Mark Brown
2022-06-20 12:54 ` [PATCH v2 3/4] arm64/cpufeature: Support AT_HWCAP3 Mark Brown
2022-06-20 12:54 ` [PATCH v2 4/4] arm64/hwcap: Support FEAT_EBF16 Mark Brown
2022-07-05 17:53 ` [PATCH v2 0/4] arm64: Add AT_HWCAP3 Mark Brown
2022-07-06 9:02 ` Szabolcs Nagy
2022-07-06 10:08 ` Marc Zyngier
2022-07-06 13:48 ` Mark Brown [this message]
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=YsWSpxUkUSGOjG4b@sirena.org.uk \
--to=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=szabolcs.nagy@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.