From: jcm@redhat.com (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: 答复: [PATCHv4] arm64: dmi: Add SMBIOS/DMI support
Date: Sun, 18 Jan 2015 22:35:47 -0500 [thread overview]
Message-ID: <54BC7B93.3090306@redhat.com> (raw)
In-Reply-To: <54BC7A52.6040006@redhat.com>
On 01/18/2015 10:30 PM, Jon Masters wrote:
> On 01/18/2015 08:27 PM, liyi 00215672 wrote:
>> Hi Jon, Leif,
>>
>> I am reviving with phoenix.liyi at huawei.com :)
>>
>> Agreed with Leif, The DMI/SMBIOS data are available for user space not for kernel level on x86, which means if DMI has some bad descriptions, it should not affect the kernel boot normally.
>>
>> So ARM platform will do the same thing, DMI data just as a reference for system configuration, and don't depend them to boot the sytem. :)
>>
>> Thanks!
>
> Thanks for the feedback! Looking forward to another visit to Shenzen soon :)
>
> I'm afraid I think we'll need to use the socket information in DMI to
> populate topology in the short term or for a vendor kernel or two. It's
> important that certain tooling accurately account the number of sockets
> present. It's awesome that ARM is going multi-socket. It's less awesome
> to see the magic words "IMPLEMENTATION DEFINED". That always means
> "abandon all hope ye who enter here". It'll need fixing in the form of a
> rigidly defined standard.
>
> I've just spent the weekend going through a variety of vendor tables and
> manually validating/correcting them/harassing people to fix various ones
> or convert to SMBIOS3. Depending upon how well this goes, we might be in
> a position to have usable data for now. With a few sanity checks, we can
> avoid using the data if it is incorrect. And in the medium term, we will
> work on a better solution such as adding topology description to ACPI
> tables. Then, we'll come back to this thread to see what is good
> upstream, once we've some informed data about what is a practical solution.
Quick footnote that I have an *embarrassingly hackish* kludged version
of dmidecode that understands how to read SMBIOS3 tables from /dev/mem
and it's working on various hardware here (using it to sanity check
vendor tables and provide feedback). I'll share a patch if useful
off-list, but I'm waiting on Linaro to post the /sys/firmware/dmi patch
this week for the solution we'd like to see in the tools upstream.
Jon.
next prev parent reply other threads:[~2015-01-19 3:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-04 15:46 [PATCHv4] arm64: dmi: Add SMBIOS/DMI support Yi Li
2014-10-06 10:40 ` Catalin Marinas
2015-01-17 5:57 ` Jon Masters
2015-01-17 12:12 ` Leif Lindholm
2015-01-17 15:09 ` Jon Masters
2015-01-19 1:27 ` 答复: " liyi 00215672
2015-01-19 3:30 ` Jon Masters
2015-01-19 3:35 ` Jon Masters [this message]
2015-01-17 16:36 ` Jon Masters
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=54BC7B93.3090306@redhat.com \
--to=jcm@redhat.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).