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