Re: decode-dimms: Module Configuration Type not reported for DDR2/3

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

Hi Andriy,

On Tue, 17 Apr 2012 23:03:16 +0300, Andriy Gapon wrote:
> on 17/04/2012 14:18 Jean Delvare said the following:
> > I am attaching two patches, one for DDR2, one for DDR3, please give
> > them a try.
> 
> Thanks a lot!
> I am able to test only the DDR2 part at the moment.
> With the patch I am getting the following
> Module Configuration Type                       Data ECC
> for these modules: http://www.valueram.com/datasheets/kvr800d2e5_2g.pdf
> 
> For some definitely non-ECC modules I get the expected
> Module Configuration Type                       No Parity

Thanks for the report, I've applied both patches.

> P.S.
> I've noticed that the "Decoding EEPROM" message is printed with
> $dimm[$current]->{eeprom} when $opt_side_by_side is true but it is printed with
> $dimm[$current]->{file} in the other case.  Not sure if this is on purpose.

I think it is on purpose. ->{file} contains the full path so it is
rather long, ->{eeprom} only contains the file name so it is much
shorter. The full path would make side-by-side output very wide, that
wouldn't be convenient, that's why the short name is used in this
output mode. In legacy output mode, the long name fits.

We _could_ use the short name in legacy output mode, as the long name
doesn't necessarily add a lot of value. I think I tried to leave the
legacy output unchanged when implementing the side-by-side output, to
avoid any regression in case someone was parsing the output of
decode-dimms. If you believe it would be better to always use the short
name, we could do that, this may even allow for a small code clean-up.

-- 
Jean Delvare