Simone/i2c-imc-skylake
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

i2c-imc-skylake: split the submission into a PCI patch and the driver

Browse Source 
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.
This commit is contained in:
Simone
2026-07-26 19:27:14 +02:00
parent e9a90d63ac
commit 3cd1d6e0a6
18 changed files with 2026 additions and 560 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/submission/0001-pci-mmcfg-accessor.patch
+204
View File
@@ -0,0 +1,204 @@
From 2bde3ce8de136654c563b0bc0b05847293bf15e5 Mon Sep 17 00:00:00 2001
From: Simone Chifari <[email protected]>
Date: Sun, 26 Jul 2026 19:24:49 +0200
Subject: [RFC PATCH v4 1/2] PCI: allow config access forced through the
memory-mapped path
On x86, raw_pci_read() and raw_pci_write() dispatch the first 256 bytes
of config space to raw_pci_ops, which is CF8/CFC whenever configuration
type 1 is usable. raw_pci_ext_ops, the memory-mapped (ECAM) path, is
only consulted from offset 0x100 upwards.
A platform that filters or drops CF8/CFC accesses to one function
therefore makes that function's low config space unreachable through the
normal accessors, even though the ECAM window reaches it. This is
observable on Intel Skylake-X boards: a dword written to the iMC SMBus
command registers at offsets 0x9C-0xB8 of the PCU function 8086:2085
does not take effect, the GO bit is never consumed and no transaction is
issued, while the same write through ECAM works. Everything else that
reads or writes that function's low config space, including setpci and
sysfs, is equally affected.
Add pci_mmcfg_read_config() and pci_mmcfg_write_config(). They take
pci_lock and honour pci_cfg_access_lock() like the other config
accessors, on top of a weak arch_pci_mmcfg_access() hook. x86
implements the hook over the existing pci_mmcfg_list, so no MCFG table
is re-parsed and no window that the architecture has already mapped is
mapped a second time. Architectures with no memory-mapped config space
keep the default, which reports -ENXIO.
These do not replace pci_read_config_dword() and friends. They are
meant for a device documented to be unreachable otherwise, and callers
are expected to justify the use in a comment.
Signed-off-by: Simone Chifari <[email protected]>
---
arch/x86/pci/mmconfig-shared.c | 28 +++++++++++
drivers/pci/access.c | 89 ++++++++++++++++++++++++++++++++++
include/linux/pci.h | 11 +++++
3 files changed, 128 insertions(+)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index acdb8dcae..715fdcdae 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -779,6 +779,34 @@ static int __init pci_mmcfg_late_insert_resources(void)
*/
late_initcall(pci_mmcfg_late_insert_resources);
+/*
+ * raw_pci_read()/raw_pci_write() dispatch the first 256 config bytes to
+ * raw_pci_ops, which is CF8/CFC whenever configuration type 1 is usable.
+ * A platform that filters CF8/CFC for one function therefore makes that
+ * function's low config space unreachable through the normal accessors,
+ * even though the ECAM window reaches it. Give the PCI core a way to
+ * select the ECAM path explicitly for such a device.
+ *
+ * See the pci_mmcfg_read_config() kerneldoc for the usage restrictions.
+ */
+int arch_pci_mmcfg_access(struct pci_dev *dev, int where, int size, u32 *val,
+ bool write)
+{
+ unsigned int seg = pci_domain_nr(dev->bus);
+ unsigned int bus = dev->bus->number;
+ int ret;
+
+ if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
+ return -ENXIO;
+
+ if (write)
+ ret = pci_mmcfg.write(seg, bus, dev->devfn, where, size, *val);
+ else
+ ret = pci_mmcfg.read(seg, bus, dev->devfn, where, size, val);
+
+ return ret < 0 ? ret : 0;
+}
+
/* Add ECAM information for host bridges */
int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
phys_addr_t addr)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index b123da16b..e058b9f2b 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -277,6 +277,95 @@ PCI_USER_WRITE_CONFIG(byte, u8)
PCI_USER_WRITE_CONFIG(word, u16)
PCI_USER_WRITE_CONFIG(dword, u32)
+/*
+ * Architecture hook for config access forced through the memory-mapped
+ * (ECAM) path. Called with @pci_lock held and interrupts disabled.
+ * Architectures without a memory-mapped config space leave the default,
+ * which reports that the path does not exist.
+ */
+int __weak arch_pci_mmcfg_access(struct pci_dev *dev, int where, int size,
+ u32 *val, bool write)
+{
+ return -ENXIO;
+}
+
+static int pci_mmcfg_access(struct pci_dev *dev, int where, int size, u32 *val,
+ bool write)
+{
+ int ret;
+
+ if (size != 1 && size != 2 && size != 4)
+ return -EINVAL;
+ if (where & (size - 1))
+ return -EINVAL;
+ if (where + size > dev->cfg_size)
+ return -EINVAL;
+ if (pci_dev_is_disconnected(dev))
+ return -ENODEV;
+
+ raw_spin_lock_irq(&pci_lock);
+ if (unlikely(dev->block_cfg_access))
+ pci_wait_cfg(dev);
+ ret = arch_pci_mmcfg_access(dev, where, size, val, write);
+ raw_spin_unlock_irq(&pci_lock);
+
+ return ret;
+}
+
+/**
+ * pci_mmcfg_read_config - read config space through the ECAM path
+ * @dev: PCI device
+ * @where: byte offset in config space, naturally aligned for @size
+ * @size: 1, 2 or 4 bytes
+ * @val: where to store the value read
+ *
+ * Read config space of @dev through the memory-mapped (ECAM) path
+ * regardless of the access method the platform selected for the first 256
+ * config bytes. On x86 that method is CF8/CFC, and some platforms filter
+ * or trap those accesses for individual functions, which makes the
+ * registers of such a function unreachable through the normal accessors.
+ *
+ * Drivers should use pci_read_config_dword() and friends. This is only
+ * for a device documented to be unreachable otherwise, and callers must
+ * be able to justify why in a comment.
+ *
+ * Must be called from a context that may sleep.
+ *
+ * Return: 0 on success, -ENXIO when the platform has no ECAM path,
+ * otherwise a negative errno. @val is set to all ones on error.
+ */
+int pci_mmcfg_read_config(struct pci_dev *dev, int where, int size, u32 *val)
+{
+ int ret;
+
+ *val = 0;
+ ret = pci_mmcfg_access(dev, where, size, val, false);
+ if (ret)
+ *val = ~0;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_mmcfg_read_config);
+
+/**
+ * pci_mmcfg_write_config - write config space through the ECAM path
+ * @dev: PCI device
+ * @where: byte offset in config space, naturally aligned for @size
+ * @size: 1, 2 or 4 bytes
+ * @val: value to write
+ *
+ * Write counterpart of pci_mmcfg_read_config(). The same restrictions
+ * apply; see that function.
+ *
+ * Return: 0 on success, -ENXIO when the platform has no ECAM path,
+ * otherwise a negative errno.
+ */
+int pci_mmcfg_write_config(struct pci_dev *dev, int where, int size, u32 val)
+{
+ return pci_mmcfg_access(dev, where, size, &val, true);
+}
+EXPORT_SYMBOL_GPL(pci_mmcfg_write_config);
+
/**
* pci_cfg_access_lock - Lock PCI config reads/writes
* @dev: pci device struct
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583..942b20dcc 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1412,6 +1412,17 @@ int pci_user_write_config_byte(struct pci_dev *dev, int where, u8 val);
int pci_user_write_config_word(struct pci_dev *dev, int where, u16 val);
int pci_user_write_config_dword(struct pci_dev *dev, int where, u32 val);
+/*
+ * Config access forced through the memory-mapped (ECAM) path. Only for
+ * devices whose registers are unreachable with the access method the
+ * platform selected for the first 256 config bytes. Both return -ENXIO on
+ * an architecture or platform that has no such path.
+ */
+int arch_pci_mmcfg_access(struct pci_dev *dev, int where, int size, u32 *val,
+ bool write);
+int pci_mmcfg_read_config(struct pci_dev *dev, int where, int size, u32 *val);
+int pci_mmcfg_write_config(struct pci_dev *dev, int where, int size, u32 val);
+
int __must_check pci_enable_device(struct pci_dev *dev);
int __must_check pci_enable_device_mem(struct pci_dev *dev);
int __must_check pci_reenable_device(struct pci_dev *);
--
2.43.0
docs/submission/Kconfig.kernel
+13 -4
View File
@@ -1,6 +1,6 @@
config I2C_IMC_SKYLAKE
tristate "Intel Skylake-X iMC SMBus adapter"
depends on PCI && ACPI && (X86_64 || COMPILE_TEST)
depends on PCI && (PCI_MMCONFIG || COMPILE_TEST)
help
Say Y here if you want kernel support for the integrated memory
controller (iMC) SMBus engine found in Intel Skylake-X / Cascade
@@ -8,11 +8,20 @@ config I2C_IMC_SKYLAKE
8086:2085).
The engine is exposed through the PCI configuration space of the
PCU function and is driven via ECAM MMIO (not CF8/CFC port I/O,
which is trapped by System Management Mode on this platform).
Two I2C adapters are registered, one per hardware SMBus channel,
PCU function. Those registers are unreachable through the config
accessors the platform selects for the first 256 bytes, so the
driver reaches them through the memory-mapped (ECAM) path. Two
I2C adapters are registered, one per hardware SMBus channel,
allowing access to DDR4 DIMM SPD EEPROMs (0x50-0x57) and thermal
sensors from userspace via standard i2c-tools and lm-sensors.
Firmware, SMM, a BMC or CLTT may drive the same engine and no
generic arbitration mechanism is known. The driver therefore
refuses to bind unless the allow_unsafe_access module parameter
is enabled. See Documentation/i2c/busses/i2c-imc-skylake.rst.
If unsure, say N. This driver is only useful on Intel X299 desktop
/ HEDT systems with the Skylake-X or Cascade Lake-X CPU.
This driver can also be built as a module. If so, the module
will be called i2c-imc-skylake.
docs/submission/cover-letter.txt
+164 -98
View File
@@ -1,120 +1,186 @@
Subject: [PATCH v3 0/1] i2c: imc-skylake: add Intel Skylake-X iMC SMBus adapter
Subject: [RFC PATCH v4 0/2] i2c: imc-skylake: Intel Skylake-X iMC SMBus adapter
This is v3 of the i2c-imc-skylake driver. v2 was submitted under the name
i2c-imc-x299; the driver has been renamed to reflect that the iMC SMBus
engine is in the Skylake-X / Cascade Lake-X CPU, not in the X299 chipset.
This series exposes the two SMBus channels of the integrated memory
controller of Intel Skylake-X and Cascade Lake-X processors as standard
Linux I2C adapters, so that DDR4 SPD EEPROMs and DIMM thermal sensors can
be read with i2c-tools, decode-dimms and lm-sensors.
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).
v3 was never posted. v2 was posted as i2c-imc-x299 and received no replies:
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.
https://lore.kernel.org/linux-i2c/[email protected]/
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:
Patch 1 is a PCI/x86 change and is the reason this is still an RFC.
Patch 2 is the driver and depends on patch 1.
PCI: Using configuration type 1 for base access
1/2 PCI: allow config access forced through the memory-mapped path
2/2 i2c: imc-skylake: add driver for the Intel Skylake-X iMC SMBus engine
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 GO bit never clears and the transaction never
completes.
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.
Why patch 1 exists
~~~~~~~~~~~~~~~~~~
The engine's registers are at config space offsets 0x9C-0xB8, inside the
first 256 bytes. On x86, raw_pci_read()/raw_pci_write() dispatch that range
to raw_pci_ops, which is CF8/CFC whenever configuration type 1 is usable
(arch/x86/pci/common.c). The extended path, raw_pci_ext_ops, is only
consulted from offset 0x100 upwards.
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).
On the tested board a dword written to the command register through
CF8/CFC does not take effect: the register reads back unchanged, the GO bit
is never consumed and no SMBus transaction is issued. The same write through
the ECAM window works, and that is how the register layout was confirmed.
Relation to prior iMC SMBus work
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two previous attempts to upstream an iMC SMBus driver exist:
This is not only a problem for this driver. If CF8/CFC writes to that
function are dropped, then setpci, sysfs and anything else the kernel does
to its low config space is equally unreliable. So rather than have a leaf
driver map the ECAM page itself, patch 1 adds
- 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.
int pci_mmcfg_read_config(struct pci_dev *, int where, int size, u32 *val);
int pci_mmcfg_write_config(struct pci_dev *, int where, int size, u32 val);
- 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.
in drivers/pci/access.c, taking pci_lock and honouring
pci_cfg_access_lock(), on top of a weak arch_pci_mmcfg_access() hook that
x86 implements over the already-validated pci_mmcfg_list. No MCFG re-parsing
and no second mapping of a window the architecture has already mapped.
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.
Questions for the PCI and x86 maintainers:
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.
- is an explicit per-access opt-in the right shape, or should a platform
that filters CF8/CFC for a function be handled by a quirk that redirects
all of its config accesses?
- if a helper is right, is drivers/pci/access.c plus a weak arch hook the
right place, or should this live entirely in arch/x86?
Independent validation
I do not consider patch 1 settled and will rework it in whatever direction
you point.
What causes the dropped write is not known. Earlier revisions of this
driver attributed it to System Management Mode; the only evidence for that
was the boot log line naming the access method, which says nothing about
who filters the write, so the attribution has been removed everywhere. The
observation stands on its own: the write does not reach the register.
Firmware arbitration
~~~~~~~~~~~~~~~~~~~~
This is the reason no iMC SMBus driver has ever been merged, and this
series does not solve it either.
Andy Lutomirski's original i2c_imc put it plainly: a BMC, the memory
controller's power management, and possibly SMM all like to touch this bus,
and Intel defined no way to arbitrate between them. That driver already had
a module parameter called allow_unsafe_access. Stefan Schaeckeler's 2020
Broadwell rewrite went further and stopped the PCU's TSOD polling for the
duration of a transfer (write 0 to TSODCNTL, wait 10 ms for in-flight
transactions to drain, restore afterwards), because on Broadwell the
original driver's consistency check tripped about every 30 minutes.
https://lwn.net/Articles/635898/
https://lore.kernel.org/linux-i2c/[email protected]/
So this driver:
- keeps the default-off allow_unsafe_access gate, deliberately the same
name as the original;
- serializes both channels under one mutex and waits for the whole engine
to be idle before touching any register;
- saves the command state of both channels, clears TSOD_ACTIVE for the
duration of the transfer, and restores both afterwards;
- after every transfer compares the command registers against what it
left in them and fails the transfer with -EAGAIN if anything else
changed. This is the check the original driver had, and it is what makes
an unarbitrated system detectable rather than silently wrong;
- requires a positive sign that the engine acted on the command, because
the done bits are latched: without that, a command that is never
accepted is indistinguishable from a completed one and the caller would
receive the previous transaction's data.
What is missing: no equivalent of Broadwell's TSODCNTL has been identified
on this part, so a system with CLTT enabled is expected to trip the
interference check rather than be arbitrated against. Finding that register
is the main open item. I would rather ship a driver that detects the
condition and refuses than one that quietly races.
Relation to prior work
~~~~~~~~~~~~~~~~~~~~~~
The register layout (DATA/STATUS/CTRL at 0x9C-0xB8, stride 4, GO bit 19,
WORD bit 17) was independently reverse-engineered and confirmed by the
PawnIO.Modules project (SmbusIntelSkylakeIMC.p, Windows userspace, Feb 2026)
and by commercial monitoring tools (HWiNFO, SIV) that access the same PCI
config space via the Windows kernel API (ECAM by default on this platform).
There is no iMC I2C driver in mainline. Lutomirski's i2c-imc was an RFC;
the 2020 resend and github.com/Linux4/i2c-imc are out of tree. Neither can
be extended to cover this part: the device ID (0x2085 vs 0x3ca8/0x6fa8),
the register layout (0x9C-0xB8 vs 0x180-0x188) and the working access
method all differ. A separate file is cleaner than a hw_data table with
mutually exclusive access paths.
The register encoding was cross-checked against an independent Windows
implementation for the same engine, which predates this work:
https://github.com/namazso/PawnIO.Modules/blob/c975ca1d1b8a9c7473a175fa1ca24d83b6cbc8f3/SmbusIntelSkylakeIMC.p
It also implements SMBus BYTE through a pointer-select bit. That is not
advertised here because it has not been validated on the Linux system, so
i2cdetect cannot scan these buses; devices are addressed directly.
Changes since v2
~~~~~~~~~~~~~~~~~
- Rename driver from i2c-imc-x299 to i2c-imc-skylake
- Fix iMC SMBus attribution: engine is in the CPU (Skylake-X), not
the X299 chipset
- Add I2C_SMBUS_WORD_DATA support (WORD_BIT bit 17) for TSOD reads
- Update adapter name: "iMC SMBus Skylake-X channel N"
- Use devm_ioremap_uc() for the ECAM mapping (uncached, strongly
ordered) instead of devm_ioremap()
- Use ARRAY_SIZE() for the adapter loop; initialise wval on the
word-read path
- Build FRAME from named bits (ENGINE_ENABLE | GO_BIT) instead of a
magic constant; document the CTRL/DATA/STATUS encoding in full
- Cross-check the iMC bus number against cfg[0xCC] at probe
- Kconfig: depends on PCI && ACPI && (X86_64 || COMPILE_TEST); drop
the CONFIG_ACPI fallback stub accordingly
- Quiet probe: demote informational probe messages to dev_dbg()
~~~~~~~~~~~~~~~~
- Split into a PCI/x86 patch and the driver; the driver no longer walks
the MCFG table or maps the ECAM page itself.
- Rename i2c-imc-x299 to i2c-imc-skylake; the engine is in the CPU, not
the chipset.
- Add the default-off allow_unsafe_access gate.
- Wait for both channels to be idle before touching the data latch.
- Preserve and restore command and TSOD state for both channels.
- Validate READ_DONE, WRITE_DONE and the hardware error state.
- Detect interference from another master and report it as -EAGAIN.
- Require a positive sign that a command was accepted.
- Add bounded command-toggle recovery for a stuck BUSY state.
- Add WORD_DATA support with the hardware byte ordering.
- Reject I2C_M_TEN explicitly and validate transfer direction.
- Use the i2c core's suspended-adapter mechanism instead of a private
flag and a non-standard errno.
- Use devm_mutex_init() and devm-managed adapters; drop the unnecessary
pci_enable_device().
- Add Documentation/i2c/busses/i2c-imc-skylake.rst.
- Drop the ACPI dependency; the Kconfig entry now depends on PCI_MMCONFIG.
- Remove the unsupported attribution of the dropped write to SMM.
Testing
~~~~~~~
Tested on: Intel X299 platform (Skylake-X CPU), 4× DDR4 DIMMs,
kernel 7.0.0-14-generic (Linux Mint 22.3).
Validation
~~~~~~~~~~
- In-tree build of both patches, W=1, x86_64, GCC: no diagnostics.
- arm64 COMPILE_TEST with Clang: no diagnostics.
- checkpatch.pl --strict: clean on both patches.
- Sparse with __CHECK_ENDIAN__: clean.
- Read-only hardware test on one Intel X299 system with four DDR4 DIMMs:
both adapters, four SPD EEPROMs, BYTE_DATA, WORD_DATA byte order, ENXIO
for an absent device, 100 concurrent reads per channel, the default-off
gate, and 20 unload/reload cycles, with no kernel warning or oops, no
interference reported and every command accepted.
$ i2cdetect -l | grep iMC
i2c-7 smbus iMC SMBus Skylake-X channel 0 SMBus adapter
i2c-8 smbus iMC SMBus Skylake-X channel 1 SMBus adapter
Still required before this can lose the RFC prefix: an independent
Tested-by, ideally on Cascade Lake-X; suspend/resume with active clients;
a measurement of MSR_SMI_COUNT across a failing CF8/CFC write, to say
something about the mechanism rather than only about the effect; and a
direction from the PCI and x86 maintainers on patch 1.
The driver supports SMBus BYTE_DATA and WORD_DATA transfers. WORD_DATA
uses the engine's WORD_BIT (bit 17) and is needed for DDR4 thermal sensors
(TSOD) which expose 16-bit temperature registers. The engine stores word
data in little-endian order in the CTRL register, so byte-swapping is applied
on both read and write paths.
Tool assistance
~~~~~~~~~~~~~~~
Per Documentation/process/generated-content.rst: this work was developed
with an AI coding assistant, run interactively rather than autonomously.
Since the hardware requires a register offset for every transaction,
I2C_SMBUS_QUICK and I2C_SMBUS_BYTE (which have no offset) are not supported
(returning -EOPNOTSUPP). For the same reason i2cdetect cannot scan the bus;
access a device directly with a byte-data read, e.g. `i2cget -y <bus> 0x50 0x02`
reads SPD byte 2. Standard kernel drivers such as ee1004 (for DDR4 SPD) load
and bind successfully via BYTE_DATA reads.
- What: Claude Code, model claude-opus-5.
- Where: it contributed to the transaction state machine of patch 2, the
kerneldoc and .rst documentation, the commit messages and this cover
letter. The register decoding, the ECAM finding and every hardware
measurement are mine.
- How it was used: iteratively, one reviewed change at a time, in
response to specific requests, not from a single generating prompt. A
representative request is "the done bits are latched; show me how a
command that is never accepted can be mistaken for a completed one, and
make that case detectable", which produced the check now in
imc_engine_responded().
- Testing: every revision was built with W=1, checked with
checkpatch --strict and sparse, and the hardware behaviour was tested
on the X299 system by me.
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.
I have reviewed all of it, I understand it, and I take responsibility for
it. The Assisted-by trailer is on patch 2, which is where the assistance
went; patch 1 was written by hand from the existing arch/x86 code.
---
Simone Chifari (1):
i2c: imc-skylake: add driver for Intel Skylake-X iMC SMBus engine
MAINTAINERS | 6 +
drivers/i2c/busses/Kconfig | 19 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-imc-skylake.c | 551 +++++++++++++++++++++++++++++++++
4 files changed, 577 insertions(+)
Simone Chifari (2):
PCI: allow config access forced through the memory-mapped path
i2c: imc-skylake: add driver for the Intel Skylake-X iMC SMBus engine
docs/submission/i2c-imc-skylake.rst
+130
View File
@@ -0,0 +1,130 @@
.. SPDX-License-Identifier: GPL-2.0
=============================
Kernel driver i2c-imc-skylake
=============================
Supported adapters:
* Intel Skylake-X / Cascade Lake-X integrated memory controller (iMC)
SMBus engine, PCU function 8086:2085 (socket LGA 2066, platform X299)
Author: Simone Chifari <[email protected]>
Description
-----------
The integrated memory controller of Intel Skylake-X and Cascade Lake-X
processors contains an SMBus engine wired to the DDR4 DIMMs. It reaches the
SPD EEPROMs (0x50-0x57) and the thermal sensors (TSOD, 0x18-0x1f) of the
installed modules, plus whatever else a particular module carries on those
lines.
The engine has two independent channels. DIMM slots 1 and 2 are on channel 0,
slots 3 and 4 on channel 1, so the driver registers two i2c adapters::
$ i2cdetect -l | grep iMC
i2c-6 smbus iMC SMBus Skylake-X channel 0 SMBus adapter
i2c-7 smbus iMC SMBus Skylake-X channel 1 SMBus adapter
Both channels share one hardware engine, so the driver serializes every
transaction across both adapters.
This driver is not enabled by default
-------------------------------------
The SMBus engine has no arbitration mechanism. System Management Mode, a BMC,
and the memory controller's own closed-loop thermal throttling (CLTT) can all
drive the same registers, and nothing in the PCI ID tells the driver whether
any of them is doing so on a given system. Two masters using the engine at the
same time can send a transaction to the wrong address or return the wrong data.
The driver therefore refuses to bind unless the operator opts in::
modprobe i2c-imc-skylake allow_unsafe_access=1
Do this only on a system where concurrent firmware access has been excluded.
Desktop and HEDT boards have no BMC, but CLTT may still be enabled by the
firmware.
The driver reduces, but cannot remove, the risk:
* every transaction waits for both channels to report idle before it
touches any register;
* the previous command state of both channels is saved, the TSOD-active
state is cleared for the duration of the transfer, and both are restored
afterwards;
* after each transfer the command registers are compared against what the
driver left in them. A difference means another master used the engine,
and the transfer is failed with ``-EAGAIN`` rather than reported as
successful.
The last check is what makes an unarbitrated system detectable: if the log
shows
``chN command changed under us (...): another master is using the engine``
then firmware is using the engine and the driver should not be loaded on that
system.
Config space access
-------------------
The engine's registers live at config space offsets 0x9C-0xB8 of the PCU
function. On x86 the first 256 bytes of config space are reached with the
access method the platform selected at boot, which is normally CF8/CFC. On the
tested board a write issued that way to the command register has no effect: the
GO bit is never consumed and no SMBus transaction is issued. The same write
through the memory-mapped (ECAM) path works.
The driver therefore uses ``pci_mmcfg_read_config()`` and
``pci_mmcfg_write_config()``, which force the ECAM path for this device. It
requires ``CONFIG_PCI_MMCONFIG``; on a system booted with ``pci=nommconf`` the
driver will fail to probe.
The mechanism that drops the CF8/CFC write has not been identified.
``MSR_SMI_COUNT`` does not increase across a failing write, so it is not
attributed to System Management Mode here.
Supported transactions
----------------------
The driver implements SMBus Read/Write Byte Data and Read/Write Word Data.
That covers ee1004 (DDR4 SPD) and jc42 (TSOD).
SMBus Quick and Receive Byte are not implemented, so ``i2cdetect`` cannot scan
these buses. Address a device directly instead, for example SPD byte 2 of the
EEPROM at 0x50::
$ i2cget -y 6 0x50 0x02
0x0c
Block transfers are not implemented. The engine has block primitives, but no
device on this bus needs them.
Word transfers use the standard SMBus byte order, so ``jc42`` reading through
``i2c_smbus_read_word_swapped()`` gets the value it expects.
Instantiating clients
---------------------
The adapter does not create ``ee1004`` or ``jc42`` clients by itself. There is
no firmware description of these buses and the driver does not scan. Create
them explicitly if you want them::
# echo ee1004 0x50 > /sys/bus/i2c/devices/i2c-6/new_device
# echo jc42 0x18 > /sys/bus/i2c/devices/i2c-6/new_device
Check first that the address is not already bound to a driver.
Module parameters
-----------------
allow_unsafe_access
Bool, read-only after load, defaults to false. The driver does not bind
unless this is set. See the section above.