dmidecode-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dmidecode] [PATCH] dmidecode: Extensions to Memory Device (Type 17)


From: Jean Delvare
Subject: Re: [dmidecode] [PATCH] dmidecode: Extensions to Memory Device (Type 17)
Date: Fri, 15 Jun 2018 09:26:23 +0200

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]