On Tue, 9 Dec 2008 04:07:20 -0800 (PST), Paul Goyette wrote: > On Tue, 9 Dec 2008, Jean Delvare wrote: > > > > > Thank you. I really don't mean to waste your time here, I just want to > > make sure that the code quality is maintained at a proper level, that > > we do not introduce any regression, and that maintaining the code in > > the future won't be too difficult. Do what you can and I'll do the rest. > > > > In fact I had already started committing some clean-ups. I'll now adjust > > your latest patch to apply on top of that. I'll let you know what I am > > done and we can pursue with DDR3 support. > > Kewl. Let me know when you have a new baseline for me to work with. > > I actually had done some of the clean-up stuff myself, but I'm more than > happy to have someone more familiar with perl to do that for me. :) Here we go. You can fetch an up-to-date version of decode-dimms with: svn export http://lm-sensors.org/svn/i2c-tools/trunk/eeprom/decode-dimms Main differences with your original patch: * readspd() only reads data from the EEPROM, it doesn't attempt to compute the size. The reason is that you don't even know if what you're reading is an SPD EEPROM yet. * All functions take a reference to the bytes array as a parameter, instead of the array itself. * Handling of Rambus types is cleaner, in particular spd_sizes() isn't called for Rambus, as I don't think it would handle it properly. Not that I really care about Rambus though, given how unpopular it is. I'm curious if anyone actually ever ran decode-dimms on Rambus. * Decoding of manufacturing information has moved to a separate function. The rest is essentially the same as the code you had provided. I think we ar ready to add support for DDR3 SDRAM now. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
