linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: wangkefeng.wang@huawei.com (Kefeng Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/3] arm64: Expose cpu vender id and model name through cpuinfo
Date: Tue, 29 Mar 2016 20:11:33 +0800	[thread overview]
Message-ID: <56FA70F5.1010606@huawei.com> (raw)
In-Reply-To: <20160329113820.GD26574@leverpostej>



On 2016/3/29 19:38, Mark Rutland wrote:
> On Fri, Mar 25, 2016 at 05:30:09PM +0800, Kefeng Wang wrote:
>> It is helpful to show the name of chip vendor and CPU model
>> to customers in cpuinfo, identify them by using CPU implementer
>> and CPU part is not intuitive(compared with x86).
> 
> On x86 these strings are acquired from the CPU itself, via CPUID
> instructions, which means that it works for future CPUs. For ARM
> systems, we have no consistent way of acquiring a model name from a CPU
> itself. Given the rate at which implementations are appearing, and
> recent experience [1] with issues mapping MIDRs to human-readable names,
> this is going to be very problematic.
> 
> We already expose the raw field values from MIDR_EL1, which are
> sufficient for a userspace application to identify a particular
> processor regardless of whether the kernel recognises it, and regardless
> of what firmware told the kernel. GCC for instance identifies CPUs based
> on MIDR_EL1 fields.
> 
> We also don't do this for arch/arm, and the two should look the same.
> 
>> We are complained for this several times, so expose them.
> 
> If you which to have human-readable strings for a CPU, a better approach
> would be to teach some userspace tool to map MIDR_EL1 values to vendor
> strings. It would be possible to update that tool when new CPUs appear,
> completely independently of the kernel.
> 
> NAK for this approach. It is not scalable, and there are other
> approaches which work today for the set of problems this tries to
> address.

Ok, clear enough, so we will push the customer to convert the impl and part
in there userspace tool, not do it in kernel.

Thanks.


> 
> Thanks,
> Mark.
> 
> [1] https://community.arm.com/groups/processors/blog/2014/09/30/arm-cortex-a17-cortex-a12-processor-update
> 

  reply	other threads:[~2016-03-29 12:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-25  9:30 [PATCH 0/3] Entend cpuinfo Kefeng Wang
2016-03-25  9:30 ` [RFC PATCH 1/3] arm64: Append more field of id_aa64mmfr2 for cpufeature Kefeng Wang
2016-03-29 12:44   ` Mark Rutland
2016-03-25  9:30 ` [RFC PATCH 2/3] arm64: Expose physical/virtual address bits through cpuinfo Kefeng Wang
2016-03-29 11:29   ` Dave Martin
2016-03-29 17:05     ` Russell King - ARM Linux
2016-03-25  9:30 ` [RFC PATCH 3/3] arm64: Expose cpu vender id and model name " Kefeng Wang
2016-03-29 11:38   ` Mark Rutland
2016-03-29 12:11     ` Kefeng Wang [this message]
2016-03-29 11:45   ` Dave Martin
2016-03-29 12:15 ` [PATCH 0/3] Entend cpuinfo Kefeng Wang

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=56FA70F5.1010606@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).