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

i2c-imc-skylake: retract the CF8/CFC claim, harden the state machine

Browse Source 
v2 said firmware filters CF8/CFC config writes to this function and that
the registers are reachable only through ECAM.  That was never tested; the
only evidence was the boot line "PCI: Using configuration type 1", which
names the accessor and says nothing about a write failing.

Measured on the board, driver unloaded:

  # setpci -s 16:1e.5 9c.L=20085002    # read SPD 0x50 register 0x02
  # setpci -s 16:1e.5 9c.L
  20005002                             # GO consumed by the engine
  # setpci -s 16:1e.5 a8.L
  0000500c                             # READ_DONE, no error
  # setpci -s 16:1e.5 b4.L
  0000000c                             # SPD byte 2, DDR4 type code

The command executes and returns correct data through the ordinary
accessors, and MSR_SMI_COUNT does not move across it.  So the driver now
uses pci_read_config_dword() and pci_write_config_dword(), the submission
is a single patch again, and nothing in it touches the PCI core.  The
cover letter retracts the claim explicitly rather than dropping it
quietly, because v2 was posted with it.

Correctness work in the same pass:

  - the completion bits are latched, so a command word that never reaches
    the register is indistinguishable from a completed transfer and the
    caller gets the previous transaction's data.  Read the command word
    back and require it to be the one just written; the engine only ever
    clears GO, which the measurement above shows directly;
  - 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.

An earlier version of the latched-DONE check required the GO bit to be
seen set or the status word to change.  That was wrong: repeated transfers
with the same outcome leave STATUS bit for bit identical, and GO is
consumed faster than a config read-back can observe it.  It produced false
positives on 3 of 15 smoke-test items before being replaced.

Add Documentation/i2c/busses/i2c-imc-skylake.rst, which every other PC
SMBus driver has and which was asked for on the 2020 iMC thread, and the
tools/ scripts for the hardware measurements: probe-cf8-write.sh and
probe-cf8-transaction.sh produced the result above, dump-pcu-config.sh is
the search for a TSOD polling control, watch-engine.sh is the firmware
activity measurement.

Smoke test on the X299 system with the current module: 15 checks, 0
failures, dmesg clean.
This commit is contained in:
Simone
2026-07-26 19:51:44 +02:00
parent 3cd1d6e0a6
commit 88a8b7eb27
13 changed files with 320 additions and 651 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/submission/0001-pci-mmcfg-accessor.patch
-204
View File
@@ -1,204 +0,0 @@
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
+2 -6
View File
@@ -1,17 +1,13 @@
config I2C_IMC_SKYLAKE
tristate "Intel Skylake-X iMC SMBus adapter"
depends on PCI && (PCI_MMCONFIG || COMPILE_TEST)
depends on PCI && (X86_64 || 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
Lake-X processors (socket LGA 2066, platform X299, PCU function
8086:2085).
The engine is exposed through the PCI configuration space of the
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,
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.
docs/submission/cover-letter.txt
+81 -105
View File
@@ -1,72 +1,50 @@
Subject: [RFC PATCH v4 0/2] i2c: imc-skylake: Intel Skylake-X iMC SMBus adapter
Subject: [PATCH v4] i2c: imc-skylake: add Intel Skylake-X iMC SMBus adapter
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.
The integrated memory controller of Intel Skylake-X and Cascade Lake-X
processors contains an SMBus engine wired to the DDR4 DIMMs. This driver
exposes its two channels 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.
v3 was never posted. v2 was posted as i2c-imc-x299 and received no replies:
v2 was posted as i2c-imc-x299 and received no replies:
https://lore.kernel.org/linux-i2c/[email protected]/
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.
v3 was never posted.
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
Correction to v2
~~~~~~~~~~~~~~~~
v2 claimed that firmware filters CF8/CFC config writes to this function and
that the registers can only be reached through the ECAM window. That claim
was wrong and I am retracting it.
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.
It was never tested directly. The only evidence behind it was the boot log
line "PCI: Using configuration type 1", which says which accessor the kernel
uses and nothing about a write failing. Measured on the same board:
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.
# setpci -s 16:1e.5 9c.L=20085002 # read SPD 0x50, register 0x02
# setpci -s 16:1e.5 9c.L
20005002 # GO consumed
# setpci -s 16:1e.5 a8.L
0000500c # READ_DONE, no error
# setpci -s 16:1e.5 b4.L
0000000c # SPD byte 2: DDR4 type code
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
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);
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.
Questions for the PCI and x86 maintainers:
- 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?
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.
The command written through CF8/CFC is executed and returns correct data,
and MSR_SMI_COUNT does not move across it. This driver therefore uses
pci_read_config_dword() and pci_write_config_dword() like any other driver.
There is no ECAM mapping, no MCFG parsing and no PCI-core change in this
series any more.
Firmware arbitration
~~~~~~~~~~~~~~~~~~~~
This is the reason no iMC SMBus driver has ever been merged, and this
series does not solve it either.
This is the reason no iMC SMBus driver has ever been merged, and this patch
does not solve it either. It does make the condition detectable.
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
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
@@ -85,41 +63,44 @@ So this driver:
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.
changed. This is the check the original driver had, and it is what
makes an unarbitrated system detectable rather than silently wrong;
- reads the command word back and requires it to be the one just
written, because the done bits are latched. With the driver unloaded
and nothing running, STATUS on the test system reads 0x0000300c:
READ_DONE and WRITE_DONE both still set from an earlier transaction.
Without the check, a command word that never reaches the register is
indistinguishable from a completed transfer and the caller receives the
previous transaction's data. The engine only ever clears GO, so that
is the single permitted difference between the two words.
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.
on this part. Offset 0xe0, where Broadwell has it, reads as zero here. A
system with CLTT enabled is therefore expected to trip the interference
check rather than be arbitrated against. I would rather ship a driver that
detects the condition and refuses than one that quietly races.
Relation to prior work
~~~~~~~~~~~~~~~~~~~~~~
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.
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) and
the register layout (0x9C-0xB8 vs 0x180-0x188) differ. A separate file is
cleaner than a hw_data table.
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
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
~~~~~~~~~~~~~~~~
- Split into a PCI/x86 patch and the driver; the driver no longer walks
the MCFG table or maps the ECAM page itself.
- Retract the CF8/CFC claim; use the ordinary config accessors. The
driver no longer maps anything.
- 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.
@@ -127,35 +108,36 @@ Changes since v2
- 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.
- Read the command word back and require it to be the one written.
- 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().
pci_enable_device(); return -ENODEV rather than -EPERM from the
default-off gate, which was logging a driver-core error on every boot.
- 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.
- Drop the ACPI dependency.
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.
- In-tree build, W=1, x86_64 GCC and arm64 Clang COMPILE_TEST: no
diagnostics.
- checkpatch.pl --strict: clean.
- 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.
- Read-only hardware test on one Intel Core i9-10900X (Cascade Lake-X)
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: 15
checks, 0 failures, no kernel warning or oops, no interference
reported, every command word confirmed in the register.
- Config space of the PCU function sampled with the driver unloaded: no
register changed on its own, and TSOD_ACTIVE was clear on both channels,
so no firmware activity was observed on this system.
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.
Still missing: an independent Tested-by, ideally on Skylake-X rather than
Cascade Lake-X, and suspend/resume testing with active I2C clients.
Tool assistance
~~~~~~~~~~~~~~~
@@ -163,24 +145,18 @@ Per Documentation/process/generated-content.rst: this work was developed
with an AI coding assistant, run interactively rather than autonomously.
- 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.
- Where: it contributed to the transaction state machine, the .rst
documentation, the commit message and this cover letter. The register
decoding is mine.
- How it was used: iteratively, one reviewed change at a time, in
response to specific requests, not from a single generating prompt. A
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().
make that case detectable", which produced imc_engine_responded(). It
also designed the measurement that retracted the CF8/CFC claim above,
after asking why that claim had never been tested directly.
- 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.
checkpatch --strict and sparse, and tested on the hardware by me.
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 (2):
PCI: allow config access forced through the memory-mapped path
i2c: imc-skylake: add driver for the Intel Skylake-X iMC SMBus engine
it.
docs/submission/i2c-imc-skylake.rst
+2 -15
View File
@@ -73,21 +73,8 @@ 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.
function and are reached with the ordinary ``pci_read_config_dword()`` and
``pci_write_config_dword()``. Nothing special is required.
Supported transactions
----------------------