I suspect that what you're referring to is not a particular issue with RAM, SPD, or "new EEPROMs", but rather with the two-wire bus that is used for communication with these EEPROMs.
I²C and SMBus are very similar busses, and are "essentially compatible".
I can only think that the lockup that you're referring to is related to the bus not returning to idle after a transaction, which is entirely possible with these busses due to their architecture - i.e: open drain with pull-ups.
Due to the way the busses operate, each of the clock (SCL) or data (SDA) signals can be in one of two states:
- High / Logic 1 - all devices set their corresponding pin to Hi-Z (high impedance / no current sinking or sourcing), which allows the pull-up resistors to bring the signal high.
- Low / Logic 0 - one or more devices can sink current to pull the relevant signal low.
Initially a master will take control of the bus, driving the clock and data lines low to address a slave device. The slave will then acknowledge the addressing by asserting the data line. For a read request, the master will then continue toggling the clock so that the slave can respond:
The master and slave will take their turn asserting the signals to transfer data between themselves. Once the transaction is complete, the bus returns to the "idle" state, where both signals are "high".
Issues can arise for a number of reasons, for example:
- "Clock Stretching" - where a slave device may legitimately request more time to deal with a request by continuing to assert the clock signal (SCL) after the master has released it... but a misbehaving device could continue to assert SCL long after it intended to.
- "Communication Errors" - where the slave perhaps didn't observe the correct number of clock cycles and remains in an active state, continuing to assert the bus.
This is where I²C and SMBus are different - crucially, SMBus specifies timeouts where I²C does not. This means that SMBus is more resilient to communication errors or other issues that can cause the bus to lockup.
The SMBus timeout is specified by way of a "minimum clock speed" - if SCL is asserted for longer than 35ms the slave device should reset its interface, returning it's SCL and SDA pins to Hi-Z.
It appears that the N34C04 you linked to the datasheet for will observe the SMBus timeout specifications, while remaining compatible with I²C busses as well.
The issue with lockups will likely be related to systems where there is an I²C device on the bus that does not observe the SMBus timeouts, and where there is corruption or the device misbehaves... The device could be a temperature sensor, an EEPROM, or a whole plethora of other devices present on the RAM module, on the mainboard, or elsewhere entirely.
The driver you linked to (ee1004.c) also explicitly states that:
We use SMBus access even if I2C is available, these EEPROMs are small
enough, and reading from them infrequent enough, that we favor simplicity
over performance.
Though remember that it is potentially the slave devices that can cause the bus to lock up.
Does anybody know more detailed information to I²C related lock up risks for new DDR4 EEPROMs? (temporarily or permanent denial of configuration changes?)
It's also important to note that the SPD is generally considered Read Only, and modifying the contents may well cause you significant issues if you don't know what you're doing.
Permanent issues are not likely, and a power cycle should clear the bus if an issue does occur, however unlikely.
Is there a risk that new kernel driver ee1004 could lock up SPD EEPROM?
I'd suggest it's very unlikely... as mentioned above, a slave device would be more likely to cause a lockup than the new driver (which is acting as an SMBus master).
