On Thu, Oct 22, 2020 at 03:55:59PM +0200, Greg Kroah-Hartman wrote:

On Thu, Oct 22, 2020 at 02:47:52PM +0100, Qais Yousef wrote:

quoted

On 10/21/20 15:41, Will Deacon wrote:

quoted

quoted

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...

I don't know what Qais thinks but a file matching the syntax of the
present/online/offline/possible files (e.g. 0-3) would look more
consistent.

-- 
Catalin

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