i2c-imc-skylake: instantiate the SPD EEPROMs at probe

Call i2c_register_spd() per adapter, like i801 and piix4, instead of
telling the user to echo into new_device. The helper counts populated
slots from DMI and probes upwards from 0x50 via i2c_new_scanned_device(),
so it claims no address that does not answer; each channel carries half
the DIMMs and the scan is per adapter, so each finds its own. Verified:
four clients on load, two per channel, none on the empty slots, and
decode-dimms works with no manual step.

This needed Receive Byte to be worth doing — without I2C_FUNC_SMBUS_BYTE
ee1004 would not have bound to what was instantiated.

The write_disable variant is deliberate. This part is DDR4 only, where
the two are equivalent (the split gates spd5118 on DDR5), and of two
equivalent calls the one that does not read as "this driver enables SPD
writes" is the better name to leave in a driver whose bus is the memory
bus. In-tree convention is write_enable; the cover letter offers to
switch.

Kconfig gains select I2C_SMBUS.

Out-of-tree, compat.h maps the call onto the older unsplit
i2c_register_spd() where that is what the target kernel has. It is force
included from the Makefile so i2c-imc-skylake.c stays byte-identical to
the submitted file, and the Makefile detects the API by grepping the
target kernel's header rather than testing a version number, which keeps
it correct on backported trees. Builds clean against both 6.8 and 7.0
headers; DKMS 1.0.2 installs on all four kernels here.

test-smoke.sh needed two fixes to keep testing what it claims:

  - A bound driver owns its address, so the raw transaction checks lost
    the SPDs the moment the driver started instantiating them. The script
    now unbinds ee1004 for the duration rather than deleting the clients:
    sysfs delete_device only removes clients that new_device created,
    and unbinding is sufficient because i2c-dev refuses an address only
    while a driver is bound (i2cdev_check: `return dev->driver ? -EBUSY
    : 0`). Rebound from an EXIT trap.

  - Those checks were guarded on an SPD address having been found, and
    when the lookup failed they vanished from the run silently: the suite
    reported "12 passed, 0 failed" while seven checks had not executed.
    Skipped checks are now counted and printed, which is how the above
    was noticed at all.

Smoke suite: 20 passed, 0 failed, 0 skipped. checkpatch --strict 0/0/0,
in-tree W=1 and Sparse clean.

docs/submission/cover-letter.txt

@@ -124,6 +124,22 @@ ee1004 consequently binds, and decode-dimms reads all four DIMMs on this
 system with both SPD CRCs valid on each.  jc42 binds where a sensor is
 populated.  i2cdetect scans in read mode.
 
+With Receive Byte in place the driver can also do what the other SMBus
+host drivers do and call i2c_register_spd() per adapter, so the SPD
+EEPROMs are instantiated at probe rather than by hand.  The helper counts
+the populated slots from DMI and probes upwards from 0x50, leaving alone
+any address that does not answer; each channel carries half the DIMMs and
+the scan is per adapter, so each finds its own.  Nothing else is
+instantiated, jc42 included: there is no firmware description of these
+buses and this driver does not scan for anything but the SPDs.
+
+I used the write_disable variant.  This part is DDR4 only, where the two
+are equivalent - the distinction gates spd5118 on DDR5 - and between two
+equivalent calls the one that does not read as "this driver enables SPD
+writes" seemed the better thing to leave in a memory-bus driver.  Happy
+to switch to write_enable for consistency with i801 and piix4 if you
+prefer the convention.
+
 SMBus Quick is still not implemented, and not only because the engine has
 no obvious encoding for it.  A write to the 0x30-0x37 range is how an
 EE1004 SPD is write-protected, permanently on many modules.  An adapter
@@ -156,6 +172,8 @@ Changes since v2
     not, ee1004 also needs Receive Byte and Send Byte.
   - Implement both, on the pointer-select bit, so ee1004 binds and
     decode-dimms works.
+  - Instantiate the SPD EEPROMs with i2c_register_spd() instead of
+    leaving it to the user.
 
 Validation
 ~~~~~~~~~~
@@ -170,11 +188,13 @@ Validation
     concurrent reads per channel, the default-off gate, and 20
     unload/reload cycles: 19 checks, 0 failures, no kernel warning or oops,
     no interference reported, every command word confirmed in the register.
-  - ee1004 bound on all four SPD addresses and decode-dimms decoded all
-    four modules, each with the CRC of bytes 0-125 and of bytes 128-253
-    valid.  The part number reads out of page 1, so the page select is
-    exercised end to end.  The four module serial numbers were identical
-    before and after every experiment in this series.
+  - i2c_register_spd() instantiated ee1004 on all four populated SPD
+    addresses at probe, two per channel, and claimed none of the empty
+    ones.  decode-dimms then decoded all four modules, each with the CRC
+    of bytes 0-125 and of bytes 128-253 valid.  The part number reads out
+    of page 1, so the page select is exercised end to end.  The four
+    module serial numbers were identical before and after every
+    experiment in this series.
   - Engine registers sampled every 2 s for one hour with the driver
     unloaded: 1791 samples, 0 changes.  No firmware activity while the
     system is up.