Two things came out of preparing the suspend test, and one of them is a
correction.
ee1004 does not bind to this adapter. Both functionality combinations it
accepts include I2C_FUNC_SMBUS_BYTE (drivers/misc/eeprom/ee1004.c:301),
which this driver does not implement, so the probe fails with
-EPFNOSUPPORT. The cover letter claimed BYTE_DATA and WORD_DATA "cover
ee1004 and jc42" and the .rst told the reader to instantiate it; both were
wrong and are corrected. jc42 is fine, it only needs BYTE_DATA and
WORD_DATA, but no TSOD is populated here to bind to.
The practical cost is that decode-dimms does not work through this adapter.
SPD bytes stay readable byte by byte with i2cget. Receive Byte is what
PawnIO implements with its pointer-select bit and what this project chose
not to advertise for want of validation; that choice was not free, and
adding it validated is the most useful thing left.
Suspend and resume tested with continuous traffic on both adapters, s2idle
and S3. Transfers recover, nothing complains. Across S3 the engine comes
back reprogrammed on both channels:
DATA 0x2000b600 -> 0x20005000
STATUS 0x0000500c -> 0x00005004
The command word addresses SPD 0x50 for a read and the status drops to
READ_DONE alone. Linux issued none of it: the adapter was marked suspended
and userspace frozen. This is consistent with firmware reading SPD during
memory training on resume, and it is the first direct observation of a
second master on this engine. It is also the concrete justification for
restoring command state per transfer and comparing it afterwards.
Add tools/test-suspend.sh, which drives that test and reports the register
delta across the sleep.
Traffic goes through i2c-dev rather than a bound client: with ee1004 unable
to attach and no TSOD present, there is no in-kernel client to use, and the
PM path exercised is the same either way -- i2c_smbus_xfer() consults
__i2c_check_suspended() before reaching the adapter.
