From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
James Morse <james.morse@arm.com>,
linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs
Date: Thu, 22 Oct 2020 15:55:59 +0200 [thread overview]
Message-ID: <20201022135559.GB1788090@kroah.com> (raw)
In-Reply-To: <20201022134752.wtcdkbi4fjn2blh6@e107158-lin>
On Thu, Oct 22, 2020 at 02:47:52PM +0100, Qais Yousef wrote:
> On 10/21/20 15:41, Will Deacon wrote:
> > > We already expose MIDR and REVIDR via the current sysfs interface. We
> > > can expand it to include _all_ the other ID_* regs currently available
> > > to user via the MRS emulation and we won't have to debate what a new
> > > interface would look like. The MRS emulation and the sysfs info should
> > > probably match, though that means we need to expose the
> > > ID_AA64PFR0_EL1.EL0 field which we currently don't.
> > >
> > > I do agree that an AArch32 cpumask is an easier option both from the
> > > kernel implementation perspective and from the application usability
> > > one, though not as easy as automatic task placement by the scheduler (my
> > > first preference, followed by the id_* regs and the aarch32 mask, though
> > > not a strong preference for any).
> >
> > If a cpumask is easier to implement and easier to use, then I think that's
> > what we should do. It's also then dead easy to disable if necessary by
> > just returning 0. The only alternative I would prefer is not having to
> > expose this information altogether, but I'm not sure that figuring this
> > out from MIDR/REVIDR alone is reliable.
>
> So the mask idea is about adding a new
>
> /sys/devices/system/cpu/aarch32_cpus
>
> ?
Is this a file, a directory, or what? What's the contents?
Without any of that, I have no idea if it's "ok" or not...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: linux-arch@vger.kernel.org, Will Deacon <will@kernel.org>,
"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
James Morse <james.morse@arm.com>, Marc Zyngier <maz@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs
Date: Thu, 22 Oct 2020 15:55:59 +0200 [thread overview]
Message-ID: <20201022135559.GB1788090@kroah.com> (raw)
In-Reply-To: <20201022134752.wtcdkbi4fjn2blh6@e107158-lin>
On Thu, Oct 22, 2020 at 02:47:52PM +0100, Qais Yousef wrote:
> On 10/21/20 15:41, Will Deacon wrote:
> > > We already expose MIDR and REVIDR via the current sysfs interface. We
> > > can expand it to include _all_ the other ID_* regs currently available
> > > to user via the MRS emulation and we won't have to debate what a new
> > > interface would look like. The MRS emulation and the sysfs info should
> > > probably match, though that means we need to expose the
> > > ID_AA64PFR0_EL1.EL0 field which we currently don't.
> > >
> > > I do agree that an AArch32 cpumask is an easier option both from the
> > > kernel implementation perspective and from the application usability
> > > one, though not as easy as automatic task placement by the scheduler (my
> > > first preference, followed by the id_* regs and the aarch32 mask, though
> > > not a strong preference for any).
> >
> > If a cpumask is easier to implement and easier to use, then I think that's
> > what we should do. It's also then dead easy to disable if necessary by
> > just returning 0. The only alternative I would prefer is not having to
> > expose this information altogether, but I'm not sure that figuring this
> > out from MIDR/REVIDR alone is reliable.
>
> So the mask idea is about adding a new
>
> /sys/devices/system/cpu/aarch32_cpus
>
> ?
Is this a file, a directory, or what? What's the contents?
Without any of that, I have no idea if it's "ok" or not...
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-22 13:55 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-21 10:46 [RFC PATCH v2 0/4] Add support for Asymmetric AArch32 systems Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 1/4] arm64: kvm: Handle " Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 12:02 ` Marc Zyngier
2020-10-21 12:02 ` Marc Zyngier
2020-10-21 13:35 ` Qais Yousef
2020-10-21 13:35 ` Qais Yousef
2020-10-21 13:51 ` Marc Zyngier
2020-10-21 13:51 ` Marc Zyngier
2020-10-21 14:38 ` Qais Yousef
2020-10-21 14:38 ` Qais Yousef
2020-11-02 17:58 ` Qais Yousef
2020-11-02 17:58 ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 2/4] arm64: Add support for asymmetric AArch32 EL0 configurations Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 15:39 ` Will Deacon
2020-10-21 15:39 ` Will Deacon
2020-10-21 16:21 ` Qais Yousef
2020-10-21 16:21 ` Qais Yousef
2020-10-21 16:52 ` Catalin Marinas
2020-10-21 16:52 ` Catalin Marinas
2020-10-21 17:39 ` Will Deacon
2020-10-21 17:39 ` Will Deacon
2020-10-22 9:53 ` Catalin Marinas
2020-10-22 9:53 ` Catalin Marinas
2020-10-21 10:46 ` [RFC PATCH v2 3/4] arm64: export emulate_sys_reg() Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 10:46 ` [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs Qais Yousef
2020-10-21 10:46 ` Qais Yousef
2020-10-21 11:09 ` Marc Zyngier
2020-10-21 11:09 ` Marc Zyngier
2020-10-21 11:25 ` Greg Kroah-Hartman
2020-10-21 11:25 ` Greg Kroah-Hartman
2020-10-21 11:46 ` Marc Zyngier
2020-10-21 11:46 ` Marc Zyngier
2020-10-21 12:11 ` Greg Kroah-Hartman
2020-10-21 12:11 ` Greg Kroah-Hartman
2020-10-21 13:18 ` Qais Yousef
2020-10-21 13:18 ` Qais Yousef
2020-10-21 12:15 ` Catalin Marinas
2020-10-21 12:15 ` Catalin Marinas
2020-10-21 13:20 ` Qais Yousef
2020-10-21 13:20 ` Qais Yousef
2020-10-21 13:33 ` Morten Rasmussen
2020-10-21 13:33 ` Morten Rasmussen
2020-10-21 14:09 ` Catalin Marinas
2020-10-21 14:09 ` Catalin Marinas
2020-10-21 14:41 ` Morten Rasmussen
2020-10-21 14:41 ` Morten Rasmussen
2020-10-21 14:45 ` Will Deacon
2020-10-21 14:45 ` Will Deacon
2020-10-21 15:10 ` Catalin Marinas
2020-10-21 15:10 ` Catalin Marinas
2020-10-21 15:37 ` Will Deacon
2020-10-21 15:37 ` Will Deacon
2020-10-21 16:18 ` Catalin Marinas
2020-10-21 16:18 ` Catalin Marinas
2020-10-21 17:19 ` Will Deacon
2020-10-21 17:19 ` Will Deacon
2020-10-22 9:55 ` Morten Rasmussen
2020-10-22 9:55 ` Morten Rasmussen
2020-10-21 14:31 ` Qais Yousef
2020-10-21 14:31 ` Qais Yousef
2020-10-22 10:16 ` Morten Rasmussen
2020-10-22 10:16 ` Morten Rasmussen
2020-10-22 10:48 ` Qais Yousef
2020-10-22 10:48 ` Qais Yousef
2020-10-21 14:41 ` Will Deacon
2020-10-21 14:41 ` Will Deacon
2020-10-21 15:03 ` Qais Yousef
2020-10-21 15:03 ` Qais Yousef
2020-10-21 15:23 ` Will Deacon
2020-10-21 15:23 ` Will Deacon
2020-10-21 16:07 ` Qais Yousef
2020-10-21 16:07 ` Qais Yousef
2020-10-21 17:23 ` Will Deacon
2020-10-21 17:23 ` Will Deacon
2020-10-21 19:57 ` Qais Yousef
2020-10-21 19:57 ` Qais Yousef
2020-10-21 20:26 ` Will Deacon
2020-10-21 20:26 ` Will Deacon
2020-10-22 8:16 ` Catalin Marinas
2020-10-22 8:16 ` Catalin Marinas
2020-10-22 9:58 ` Qais Yousef
2020-10-22 9:58 ` Qais Yousef
2020-10-22 13:47 ` Qais Yousef
2020-10-22 13:47 ` Qais Yousef
2020-10-22 13:55 ` Greg Kroah-Hartman [this message]
2020-10-22 13:55 ` Greg Kroah-Hartman
2020-10-22 14:31 ` Catalin Marinas
2020-10-22 14:31 ` Catalin Marinas
2020-10-22 14:34 ` Qais Yousef
2020-10-22 14:34 ` Qais Yousef
2020-10-26 19:02 ` Qais Yousef
2020-10-26 19:02 ` Qais Yousef
2020-10-26 19:08 ` Greg Kroah-Hartman
2020-10-26 19:08 ` Greg Kroah-Hartman
2020-10-26 19:18 ` Qais Yousef
2020-10-26 19:18 ` Qais Yousef
2020-10-21 11:28 ` Greg Kroah-Hartman
2020-10-21 11:28 ` Greg Kroah-Hartman
2020-10-21 13:22 ` Qais Yousef
2020-10-21 13:22 ` Qais Yousef
2020-10-21 11:26 ` [RFC PATCH v2 0/4] Add support for Asymmetric AArch32 systems Greg Kroah-Hartman
2020-10-21 11:26 ` Greg Kroah-Hartman
2020-10-21 13:15 ` Qais Yousef
2020-10-21 13:15 ` Qais Yousef
2020-10-21 13:31 ` Greg Kroah-Hartman
2020-10-21 13:31 ` Greg Kroah-Hartman
2020-10-21 13:55 ` Qais Yousef
2020-10-21 13:55 ` Qais Yousef
2020-10-21 14:35 ` Catalin Marinas
2020-10-21 14:35 ` Catalin Marinas
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=20201022135559.GB1788090@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=torvalds@linux-foundation.org \
--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.