All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Andrew Murray <andrew.murray@arm.com>
Cc: Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, nd <nd@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2
Date: Thu, 28 Mar 2019 11:27:36 +0000	[thread overview]
Message-ID: <20190328112734.GZ3567@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20190327152414.GF43527@e119886-lin.cambridge.arm.com>

On Wed, Mar 27, 2019 at 03:24:15PM +0000, Andrew Murray wrote:
> On Wed, Mar 27, 2019 at 03:02:25PM +0000, Andrew Murray wrote:

[...]

> > I'll add documentation to Documentation/arm64 to indicate that the upper 32bits
> > of AT_HWCAP will always be 0. Is this correct? 
> 
> How about this (in Documentation/arm64/elf_hwcaps.txt)?
> 
> +
> +
> +4. Unused AT_HWCAP bits
> +-----------------------
> +
> +Each AT_HWCAP and AT_HWCAP2 entry provides for up to 32 hwcaps contained
> +in bits [31:0]. For interoperation with userspace we guarantee that the
> +top bits [63:32] of AT_HWCAP will always be returned as 0.

Since the main reason for reserving bits [63:32] is ILP32, and it's
still unclear when (or if) that will be merged, it feels a bit excessive
to promise that we will never use these bits.

It sounds like glibc has a use for at most one bit in here.

So maybe we can reserve bit 63 (or 32, whatever) and promise that is
zero, but leave the rest uncommitted for now.

Szabolcs, does that sound sensible?

Cheers
---Dave


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-28 11:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-21 12:20 [PATCH v2 0/6] Initial support for CVADP Andrew Murray
2019-02-21 12:20 ` [PATCH v2 1/6] arm64: Handle trapped DC CVADP Andrew Murray
2019-02-21 12:39   ` Mark Rutland
2019-02-21 12:20 ` [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2 Andrew Murray
2019-02-21 18:45   ` Dave P Martin
2019-02-22 10:35     ` Szabolcs Nagy
2019-03-27 15:02       ` Andrew Murray
2019-03-27 15:24         ` Andrew Murray
2019-03-28 11:27           ` Dave Martin [this message]
2019-03-29 16:44             ` Szabolcs Nagy
2019-03-29 16:57               ` Phil Blundell
2019-04-01  8:14                 ` Andrew Murray
2019-03-27 14:53     ` Andrew Murray
2019-03-29 15:39   ` Dave Martin
2019-02-21 12:20 ` [PATCH v2 3/6] arm64: HWCAP: encapsulate elf_hwcap Andrew Murray
2019-02-21 18:45   ` Dave P Martin
2019-03-27 14:03     ` Andrew Murray
2019-03-28 11:32       ` Dave Martin
2019-02-21 12:20 ` [PATCH v2 4/6] arm64: Expose DC CVADP to userspace Andrew Murray
2019-02-21 12:20 ` [PATCH v2 5/6] arm64: add CVADP support to the cache maintenance helper Andrew Murray
2019-02-21 12:20 ` [PATCH v2 6/6] arm64: Advertise ARM64_HAS_DCPODP cpu feature Andrew Murray

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=20190328112734.GZ3567@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Szabolcs.Nagy@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=andrew.murray@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nd@arm.com \
    /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.