linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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.

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