[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