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

[Jerry Hoemann]

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