[PATCH v2 0/1] i2c: imc-x299: add Intel X299 iMC SMBus adapter

[Simone Chifari <simone.chifari@gmail.com>]

This series adds a driver for the integrated memory controller (iMC) SMBus
engine on Intel Skylake-X / Cascade Lake-X processors (socket LGA 2066,
platform X299, PCU function 8086:2085).

The engine provides two SMBus channels — one per pair of DIMM slots — over
which SPD EEPROMs, DDR4 thermal sensors and third-party LED controllers
(e.g. ENE KB9012 at 0x27) are accessible.  Exposing it as a pair of standard
Linux I2C adapters lets existing tools (i2c-tools, lm-sensors) use
it without bespoke sysfs hacks.

Why ECAM MMIO instead of pci_{read,write}_config_dword
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On X299 the kernel selects "configuration type 1" (CF8/CFC port I/O) for PCI
config space access, as reported by boot-time dmesg:

  PCI: Using configuration type 1 for base access

System Management Mode traps writes to those ports for this device, so a
standard pci_write_config_dword() targeting the SMBus DATA register never
reaches the hardware — the transaction hangs at status bit 0x08 indefinitely.
The Windows NTIOLib (used by Kingston FURY) reaches the same registers via the
ECAM (MMIO) window, which is not trapped.  This driver follows the same path:
ioremap() of the ECAM page for the target function and driving the registers
by MMIO read/write.

Note that pci_mmcfg_* helpers are arch-internal and not exported to modules,
so a manual walk of the ACPI MCFG table is used to locate mmcfg_base at probe
time (no module parameter, no hardcoding).

Relation to prior iMC SMBus work
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two previous attempts to upstream an iMC SMBus driver exist:

  - Lutomirski 2013–2016 (Sandy Bridge-EP 8086:3ca8): used CF8/CFC
    pci_read/write_config_dword — correct on that platform since SMM does not
    trap those ports on Sandy Bridge-EP.  Not merged due to missing bus
    arbitration (BMC / CLTT sharing) and a required allow_unsafe_access flag.

  - schaecsn 2020 (Broadwell-E 8086:6fa8): added TSOD arbitration using the
    Broadwell-documented tsod_polling_interval quiesce procedure.  Not merged
    (no reviewer response); register layout differs from X299.

This driver is for a different device ID (0x2085), different register layout
(DATA/STATUS/CTRL at 0x9C-0xB8 vs 0x180-0x188), and a fundamentally different
access method (ECAM ioremap).  Combining it with the Lutomirski/schaecsn code
would require a large per-generation hw_data table with mutually incompatible
access methods; a separate file is cleaner.

The X299 HEDT (High-End Desktop) platform has no BMC and no CLTT firmware
polling, so the arbitration safety concern of the Lutomirski patch does not
apply.  No allow_unsafe_access flag is needed.

Testing
~~~~~~~
Tested on: ASUS TUF X299 Mark 1, Intel Core i9-10900X, 4× Kingston FURY
HyperX DDR4-3000 16 GB, kernel 7.0.0-14-generic (Linux Mint 22.3).

  $ i2cdetect -l | grep iMC
  i2c-7   smbus   iMC SMBus X299 channel 0   SMBus adapter
  i2c-8   smbus   iMC SMBus X299 channel 1   SMBus adapter

Since the hardware only supports register-offset transactions (SMBus BYTE_DATA),
zero-length writes (QUICK) and offset-less transactions (BYTE) are not supported
(returning -EOPNOTSUPP), so standard i2cdetect scans do not list devices.
However, standard kernel drivers such as ee1004 (for DDR4 SPD) load and bind
successfully, accessing the EEPROMs via standard BYTE_DATA reads.

udev autoloads the module on PCI add event (MODULE_DEVICE_TABLE present).
20 rmmod/modprobe cycles: no oops, no warnings, no resource leaks in dmesg.

Simone Chifari (1):
  i2c: imc-x299: add driver for Intel X299/Skylake-X iMC SMBus engine

 MAINTAINERS                       |   6 +
 drivers/i2c/busses/Kconfig        |  19 ++
 drivers/i2c/busses/Makefile       |   1 +
 drivers/i2c/busses/i2c-imc-x299.c | 435 ++++++++++++++++++++++++++++++
 4 files changed, 461 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-imc-x299.c

-- 
2.43.0