Sostituzione meccanica dei segnali, nessun cambio di contenuto:
- β οΈ β π¨ e π§ β βΈοΈ, scelte di Simone il 2026-08-24
- β/π β β e π β βΉοΈ, ritirati dalla spec del 2026-08-22
- β seguito da U+FE0F, se no il font di testo lo rende come una Γ sottile
Fatta con wiki/bin/cambia-segnale.py e wiki/bin/fix-emoji-fe0f.py, che saltano
blocchi di codice, span fra backtick e symlink, e non muovono il mtime.
Vocabolario: wiki/docs/specs/2026-08-22-segnali-e-colori.md
P2 asked whether the ENE at 0x27 has readable state. The answer had been
reached twice by elimination, and the last link in that chain was a comment
in a third party's patched OpenRGB detector, not a measurement of ours.
probe-ene-receive-byte.sh runs the experiment the driver made possible on
2026-07-27, when PNTR_SEL (BIT(18)) gave us a bare Receive Byte: a read with
no command byte on the wire cannot return a transform of a register that was
never sent. It does, however, return the last command byte the chip received
β 12/12 on both channels β so the value is still ours, not the device's. A
Receive Byte taken from 0x31 after addressing 0x27 answers 0xff instead of
the echo, which places the latch in the device and not in the iMC engine;
empty addresses NACK, so the transaction is real.
Everything here is read-only: Receive Byte and Read Byte Data at 0x27, SPD
reads through ee1004 sysfs, and the four SPD serials compared before and
after every run.
Two engine behaviours the script has to work around, both measured:
the first transaction on a channel answers with a stale value (hence the
discarded warm-up read), and a read following a successful one usually
NACKs, which one retry always clears β the P1 policy, confirmed.
lore-thread-check.py is unrelated to the probe but shares the same motive:
lore and patchwork now sit behind an Anubis bot check, so a shell cannot
tell "not published" from "not allowed to look". The NNTP mirror can.
The engine encodes an address-only transaction in command word bit 18,
which is what SMBus Receive Byte and Send Byte need and what was missing
for ee1004 to bind.
The bit is not documented for the PCU function. It was located by
structure rather than by sweeping: SMBCMD on the iMC channel function
(datasheet ref. 614073 section 3.1.8) places PNTR_SEL immediately above
WORD_ACCESS, and word access here is bit 17. Bit 17 had itself been
unknown until it turned out to be word access, and an earlier sweep of
this register covered bits 31:20 only, so 18 was untried rather than
already ruled out.
Validated against the device rather than against the register. An EEPROM
auto-increments its pointer after a read, so priming the pointer and
repeating the read with the bit set has a predicted answer: the next
byte, not the one named. Eight consecutive reads returned SPD bytes 0x01
through 0x08 in order, matching an ordinary dump. Send Byte was confirmed
on the DDR4 page-select addresses, which hold a latch and store no data,
so the page state is itself the readout.
Result: ee1004 binds on all four SPD addresses and decode-dimms decodes
all four modules with both CRCs valid on each. The part number comes off
page 1, so the page select runs end to end. The four module serial
numbers are unchanged from the baseline recorded before this series.
SMBus Quick stays unimplemented. Beyond having no obvious encoding, a
write into the 0x30-0x37 range is how an EE1004 SPD is write-protected,
permanently on many modules, so an adapter on the memory bus should not
advertise a probe that writes. i2cdetect scans in read mode.
Also fix test-smoke.sh resolving the module through modinfo, which
silently tested the installed DKMS build instead of the one just
compiled. It now prefers the local .ko and prints which it loaded.
Smoke suite: 19 passed, 0 failed. checkpatch --strict 0/0/0, in-tree W=1
and Sparse clean.
The driver reached the PCU function's config space by walking the ACPI MCFG
table and mapping the ECAM page itself. That is one leaf driver deciding
config-space policy, and no other driver in mainline does it, so it was the
single most likely reason for a NAK.
Move that decision where it belongs: the upstream series is now two patches,
a PCI/x86 accessor that forces the memory-mapped path with the core's
locking, and this driver on top of it. Reviewers on each side now get
something they can act on, and get_maintainer.pl selects the PCI and x86
people by itself.
Correctness work in the same pass:
- the completion bits are latched, so a command the engine never accepted
was indistinguishable from a completed one and returned the previous
transaction's data as valid. Require a positive sign that the engine
acted on the command;
- compare the command registers after every transfer against what the
driver left in them and fail with -EAGAIN on a mismatch. The original
iMC driver had this check and it is what makes an unarbitrated system
detectable instead of silently wrong;
- use the i2c core's suspended-adapter mechanism rather than a private
flag and -EHOSTDOWN;
- use devm_mutex_init(), drop the unnecessary pci_enable_device(), and
return -ENODEV rather than -EPERM from the default-off gate, which was
printing a driver-core error on every boot;
- mask GO when restoring a saved command word.
Stop attributing the dropped CF8/CFC write to System Management Mode. The
only evidence was a boot log line naming the access method, which says
nothing about who filters the write. tools/probe-cf8-write.sh is there to
settle it with an MSR_SMI_COUNT measurement.
Add Documentation/i2c/busses/i2c-imc-skylake.rst, which every other PC SMBus
driver has and which was explicitly asked for on the 2020 iMC thread, the
tools/ scripts for the hardware measurements the submission still owes, and
compat/pci-mmcfg-compat.h so the driver still builds out-of-tree against a
kernel without the new accessor while the source stays byte-identical to the
submitted patch.
Simone