Simone
3cd1d6e0a6
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.
28 lines
1.3 KiB
Plaintext
28 lines
1.3 KiB
Plaintext
config I2C_IMC_SKYLAKE
|
|
tristate "Intel Skylake-X iMC SMBus adapter"
|
|
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
|
|
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,
|
|
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.
|