[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dmidecode] [PATCH] dmidecode: Extensions to Memory Device (Type 17)
From: |
Jerry Hoemann |
Subject: |
Re: [dmidecode] [PATCH] dmidecode: Extensions to Memory Device (Type 17) |
Date: |
Fri, 15 Jun 2018 14:44:41 -0600 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
On Fri, Jun 15, 2018 at 09:26:23AM +0200, Jean Delvare wrote:
> Hi Jerry,
>
> On Thu, 14 Jun 2018 18:14:55 -0600, Jerry Hoemann wrote:
> > > +static void dmi_memory_manufacturer_id(u16 code)
> > > +{
> > > + /* 7.18.8 */
> > > + /* 7.18.10 */
> > > + /* LSB is 7-bit Odd Parity number of continuation codes. */
> > > + if (code == 0)
> > > + printf(" Unknown");
> > > + else
> > > + printf(" Bank %d, Hex 0x%2X", (code & 0x7f) + 1, code >> 8);
> > > +}
> >
> >
> > Robert pointed me to
> >
> > ] Here's a GPLv2 open-source program that includes JEP106 manufacturer
> > decoding:
> > ] https://github.com/ntfreak/openocd
> > ]
> > ] see src/helper/jep106.c, .h, and .inc.
> >
> >
> > This could be adapted to print the manufacturer name in dmidecode.
> > There are quite a few IDs (~1200) and more keep getting added.
> >
> > I was curious as to your thoughts in decoding the names.
>
> I didn't know about openocd, but decode-dimms from i2c-tools project
> also includes that list:
>
> https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/tree/eeprom/decode-dimms#n55
>
> And yes, it is large and constantly growing. I'm a bit reluctant to
> duplicate it once more in dmidecode.
>
> I believe it would make sense to have that list stored in a text file
> under /usr/share, like we have /usr/share/pci.ids for PCI vendors and
> devices. If something like that existed, then I would be happy to let
> dmidecode try and read that file to optionally include the memory
> vendor names in its output. I would also update decode-dimms to make
> use of it.
For the purpose of this patch, I'll continue with the current
approach.
We can look into something along the lines of pci.ids in
a future patch.
>
> > > (...)
> > > +static void dmi_memory_size(u64 code)
> > > +{
> > > + if (code.h == 0xFFFFFFFF && code.l == 0xFFFFFFFF)
> > > + printf(" Unknown");
> > > + else
> > > + printf(" 0x%08X%08X", code.h, code.l);
> > > +}
> >
> >
> > It was also suggested that the size in MiB or GiB be used
> > here in stead.
>
> Agreed, that will make the value a lot easier to read. We already do
> something like that in dmi_print_memory_size(), which you may be able
> to reuse or refactor somehow.
>
> --
> Jean Delvare
> SUSE L3 Support
--
-----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-----------------------------------------------------------------------------