Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V2] arm64/cpuinfo: Move HWCAP name arrays alongside their bit definitions
Date: Thu, 14 May 2020 08:36:13 +0100	[thread overview]
Message-ID: <20200514073613.GB4280@willie-the-truck> (raw)
In-Reply-To: <0999fa28-3ee7-3f02-4def-a0c6013ec6dd@arm.com>

On Thu, May 14, 2020 at 07:14:58AM +0530, Anshuman Khandual wrote:
> On 05/13/2020 08:34 PM, Dave Martin wrote:
> > On Thu, May 07, 2020 at 06:59:10PM +0530, Anshuman Khandual wrote:
> >> diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
> >> index 0f00265248b5..589ac02e1ddd 100644
> >> --- a/arch/arm64/include/asm/hwcap.h
> >> +++ b/arch/arm64/include/asm/hwcap.h
> >> @@ -8,18 +8,27 @@
> >>  #include <uapi/asm/hwcap.h>
> >>  #include <asm/cpufeature.h>
> >>  
> >> +#define COMPAT_HWCAP_SWP	(1 << 0)
> >>  #define COMPAT_HWCAP_HALF	(1 << 1)
> >>  #define COMPAT_HWCAP_THUMB	(1 << 2)
> >> +#define COMPAT_HWCAP_26BIT	(1 << 3)
> >>  #define COMPAT_HWCAP_FAST_MULT	(1 << 4)
> >> +#define COMPAT_HWCAP_FPA	(1 << 5)
> >>  #define COMPAT_HWCAP_VFP	(1 << 6)
> >>  #define COMPAT_HWCAP_EDSP	(1 << 7)
> >> +#define COMPAT_HWCAP_JAVA	(1 << 8)
> >> +#define COMPAT_HWCAP_IWMMXT	(1 << 9)
> >> +#define COMPAT_HWCAP_CRUNCH	(1 << 10)
> >> +#define COMPAT_HWCAP_THUMBEE	(1 << 11)
> >>  #define COMPAT_HWCAP_NEON	(1 << 12)
> >>  #define COMPAT_HWCAP_VFPv3	(1 << 13)
> >> +#define COMPAT_HWCAP_VFPV3D16	(1 << 14)
> >>  #define COMPAT_HWCAP_TLS	(1 << 15)
> >>  #define COMPAT_HWCAP_VFPv4	(1 << 16)
> >>  #define COMPAT_HWCAP_IDIVA	(1 << 17)
> >>  #define COMPAT_HWCAP_IDIVT	(1 << 18)
> >>  #define COMPAT_HWCAP_IDIV	(COMPAT_HWCAP_IDIVA|COMPAT_HWCAP_IDIVT)
> >> +#define COMPAT_HWCAP_VFPD32	(1 << 19)
> >>  #define COMPAT_HWCAP_LPAE	(1 << 20)
> >>  #define COMPAT_HWCAP_EVTSTRM	(1 << 21)
> > 
> > With the possible exception of SWP (does the swp emulation allow us to
> > report this as supported?), I think all these weren't mentioned because
> > they aren't included in ARMv8 and so can never be reported.
> > 
> > If we find ourselves reporting them, there's a bug somewhere.
> > 
> > So, can we just default all obsolete string entries to NULL?
> > 
> > When generating the cpuinfo strings we could WARN and just emit an empty
> > string for that hwcap.
> 
> All these above will be a change in the existing user visible behavior on
> the system and this patch never intended to create one.

Why is it a change? We've never reported e.g. "java" on an arm64 kernel, so
I agree with Dave that we shouldn't be adding this string. If it /ever/ ends
up in userspace it's because something has gone horribly wrong. NULL would
be much better. Couldn't you achieve that by simply omitting these entries?
e.g. deleting things like:

	[COMPAT_KERNEL_HWCAP(JAVA)]     = "java",

completely (including the COMPAT_HWCAP_JAVA definition)?

> Hence, I will just defer this to maintainers on whether we should change
> existing /proc/cpuinfo output (including non-practically-possible ones on
> ARMv8) or even treat swap emulation as SWP.

SWP is fine because we emulate it and so userspace can use it. Removing that
*would* be a change in behaviour. I don't think the compat ABI is broken
here, so please don't change it without good reason.

Will

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

  reply	other threads:[~2020-05-14  7:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 13:29 [PATCH V2] arm64/cpuinfo: Move HWCAP name arrays alongside their bit definitions Anshuman Khandual
2020-05-13 15:04 ` Dave Martin
2020-05-14  1:44   ` Anshuman Khandual
2020-05-14  7:36     ` Will Deacon [this message]
2020-05-15  3:28       ` Anshuman Khandual
2020-05-18 22:35         ` Will Deacon
2020-05-20  0:27           ` Anshuman Khandual

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=20200514073613.GB4280@willie-the-truck \
    --to=will@kernel.org \
    --cc=Dave.Martin@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox