docs: stop printing a bus number the reader should look up

The verification section told the reader to find the adapter with
i2cdetect -l and then handed them "i2cdetect -y -r 6" to paste, along
with a 6-0050 sysfs path and an i2c-6 new_device path. Bus numbers are
handed out in probe order and move: on the development machine the iMC
channels are now 7 and 8, and 6 is the PCH i801 adapter, so the example
scans the wrong bus and finds nothing.

Derive the number once into $CH0 and use it everywhere, and say that the
sample output is one machine's assignment rather than a constant.

Also note that the SPD addresses report as UU. They are instantiated at
probe now, so a correct scan shows no number there, which reads like a
failed probe if the page does not say otherwise.

README.md

@@ -156,8 +156,16 @@ i2cdetect -l | grep iMC
 ```
 
 ```text
-i2c-6   smbus           iMC SMBus Skylake-X channel 0                SMBus adapter
-i2c-7   smbus           iMC SMBus Skylake-X channel 1                SMBus adapter
+i2c-7   smbus           iMC SMBus Skylake-X channel 0                SMBus adapter
+i2c-8   smbus           iMC SMBus Skylake-X channel 1                SMBus adapter
+```
+
+Bus numbers are handed out in probe order, so they move between boots and
+kernels — the numbers above are what one machine happened to get, not fixed
+values. Take them from the command, not from this page:
+
+```bash
+CH0=$(i2cdetect -l | sed -n 's/^i2c-\([0-9]*\).*iMC SMBus.*channel 0.*/\1/p')
 ```
 
 The driver implements SMBus Receive Byte, Send Byte, BYTE_DATA and WORD_DATA.
@@ -165,22 +173,24 @@ SMBus Quick is deliberately not implemented (a write probe into `0x30`-`0x37`
 is how an EE1004 SPD is write-protected), so scan in read mode:
 
 ```bash
-sudo i2cdetect -y -r 6
+sudo i2cdetect -y -r "$CH0"
 ```
 
 SPD EEPROMs are instantiated automatically at probe (`ee1004`, counted from
-DMI), so `decode-dimms` works with no manual step. `ee1004` owns those
-addresses once bound: read the SPD through the driver, not with raw `i2cget`:
+DMI), so `decode-dimms` works with no manual step. Those addresses report as
+`UU` instead of as a number: a kernel driver owns them, which is the expected
+result and not a failed probe. Read the SPD through the driver, not with raw
+`i2cget`:
 
 ```bash
-sudo cat /sys/bus/i2c/devices/6-0050/eeprom | hexdump -C | head
+sudo cat "/sys/bus/i2c/devices/$CH0-0050/eeprom" | hexdump -C | head
 ```
 
 `jc42` is not instantiated (no firmware description of these buses); add it by
 hand where a thermal sensor is populated:
 
 ```bash
-echo jc42 0x18 | sudo tee /sys/bus/i2c/devices/i2c-6/new_device
+echo jc42 0x18 | sudo tee "/sys/bus/i2c/devices/i2c-$CH0/new_device"
 ```
 
 Read-only integration test against the module just built: