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/i2c-imc-skylake.rst

@@ -129,22 +129,27 @@ Word transfers use the standard SMBus byte order, so ``jc42`` reading through
 Instantiating clients
 ---------------------
 
-The adapter does not create clients by itself.  There is no firmware
-description of these buses and the driver does not scan.
+SPD EEPROMs are instantiated at probe with ``i2c_register_spd()``, like the
+other SMBus host drivers.  It counts the populated slots from DMI and probes
+from 0x50 upwards, so an address that does not answer is left alone.  Each
+channel carries half the DIMMs and the scan runs per adapter, so each finds
+its own::
 
-``jc42`` can be instantiated where a thermal sensor is populated::
+    i2c i2c-6: Successfully instantiated SPD at 0x50
+    ee1004 6-0050: 512 byte EE1004-compliant SPD EEPROM, read-only
+
+``decode-dimms`` therefore works with no manual step.
+
+Nothing else is instantiated: there is no firmware description of these buses
+and the driver does not scan for anything but the SPDs.  ``jc42`` has to be
+added by hand where a thermal sensor is populated::
 
     # echo jc42 0x18 > /sys/bus/i2c/devices/i2c-6/new_device
 
 Whether one is populated is visible in ``SMBCNTL.TSOD_PRESENT``; on the
 development system that mask is empty and no ``jc42`` binds.
 
-``ee1004`` binds on each populated SPD address::
-
-    # echo ee1004 0x50 > /sys/bus/i2c/devices/i2c-6/new_device
-    ee1004 6-0050: 512 byte EE1004-compliant SPD EEPROM, read-only
-
-Two things are worth knowing before instantiating it on this bus.
+Two things about the SPDs are worth knowing on this bus.
 
 A DDR4 SPD is a 512-byte array reached through a 256-byte window, and which
 half is visible is a property of the bus, not of the transfer.  ``ee1004``
@@ -154,11 +159,14 @@ reading SPD by hand::
 
     # i2cset -y 6 0x36 0x00 c
 
-And a bound ``ee1004`` owns those addresses, so userspace can no longer reach
-them through ``/dev/i2c-*``.  That matters more here than on a mainboard SMBus,
-because the tools that motivate this driver share the bus with the SPDs.  Bind
-``ee1004`` when you want ``decode-dimms``, and remove it when you want the
-addresses back::
+And ``ee1004`` owns those addresses once bound, so userspace cannot reach them
+through ``/dev/i2c-*`` any more.  This is ordinary I2C behaviour, but it is
+worth stating here because the userspace tools that motivate this driver share
+the bus with the SPDs.  Read the SPD through the driver instead::
+
+    $ cat /sys/bus/i2c/drivers/ee1004/6-0050/eeprom | hexdump -C
+
+or, if an address really is needed raw, release it::
 
     # echo 0x50 > /sys/bus/i2c/devices/i2c-6/delete_device