mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Måns Rullgård" <mans@mansr.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	Russell King <linux@arm.linux.org.uk>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm\@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Rob Clark <robdclark@gmail.com>
Subject: Re: [PATCH v2 2/3] ARM: vfp: Fix VFPv3 hwcap detection on CPUID based cpus
Date: Mon, 27 Oct 2014 11:49:15 +0000	[thread overview]
Message-ID: <yw1xppddwx50.fsf@unicorn.mansr.com> (raw)
In-Reply-To: <20141027103118.GA8768@arm.com> (Will Deacon's message of "Mon, 27 Oct 2014 10:31:18 +0000")

Will Deacon <will.deacon@arm.com> writes:

> Perhaps it would be better to consider exposing the ID registers to
> userspace in some manner? This could be done either via an undef handler, or
> using the vdso. We would add a (final) hwcap advertising this cpuid support.
> For big/little systems, the kernel would need to expose a suitable subset of
> the features (we already have the sanity checking code from Rutland).

This was discussed a few years ago, and some people raised various
objections.  Off the top of my head:

- Some features (e.g. VFP/NEON) need kernel support, and if this is not
  enabled, the actual system capabilities will not match the raw
  register value.  Fudging the values exposed to userspace would be
  fragile.
  (This argument has some merit.)

- Only v7 and newer CPUs have the CPUID registers.  Ridiculously old
  CPUs don't even have a CP15.  Providing synthetic values might be
  tricky.  Software thus needs to support alternate feature detection
  methods for such hardware.
  (This is true enough.)

- It would only be available on new kernels, so software would still
  need a fallback to another method for the foreseeable future.
  (This is a rather lazy argument.)

- It would be specific to Linux, so software can't rely on it anyway.
  (This is an even lazier argument.)

-- 
Måns Rullgård
mans@mansr.com

  reply	other threads:[~2014-10-27 11:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-14 13:48 [PATCH v2 0/3] VFP fixes Stephen Boyd
2014-10-14 13:48 ` [PATCH v2 1/3] ARM: vfp: Workaround bad MVFR1 register on some Kraits Stephen Boyd
2014-10-14 13:48 ` [PATCH v2 2/3] ARM: vfp: Fix VFPv3 hwcap detection on CPUID based cpus Stephen Boyd
2014-10-27 10:31   ` Will Deacon
2014-10-27 11:49     ` Måns Rullgård [this message]
2014-10-27 19:50     ` Stephen Boyd
2014-10-28 12:11       ` Will Deacon
2014-10-28 17:54         ` Stephen Boyd
2014-10-14 13:48 ` [PATCH v2 3/3] arm: vfp: Bounce undefined instructions in vectored mode Stephen Boyd
2014-10-16 13:14 ` [PATCH v2 0/3] VFP fixes Rob Clark

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=yw1xppddwx50.fsf@unicorn.mansr.com \
    --to=mans@mansr.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=robdclark@gmail.com \
    --cc=sboyd@codeaurora.org \
    --cc=will.deacon@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

Powered by JetHome