mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-10-01 14:44:12 +00:00
8dd2bc0f8e
At this point the subsystem can enumerate all CXL ports (CXL.mem decode resources in upstream switch ports and host bridges) in a system. The last mile is connecting those ports to endpoints. The cxl_mem driver connects an endpoint device to the platform CXL.mem protoctol decode-topology. At ->probe() time it walks its device-topology-ancestry and adds a CXL Port object at every Upstream Port hop until it gets to CXL root. The CXL root object is only present after a platform firmware driver registers platform CXL resources. For ACPI based platform this is managed by the ACPI0017 device and the cxl_acpi driver. The ports are registered such that disabling a given port automatically unregisters all descendant ports, and the chain can only be registered after the root is established. Given ACPI device scanning may run asynchronously compared to PCI device scanning the root driver is tasked with rescanning the bus after the root successfully probes. Conversely if any ports in a chain between the root and an endpoint becomes disconnected it subsequently triggers the endpoint to unregister. Given lock depenedencies the endpoint unregistration happens in a workqueue asynchronously. If userspace cares about synchronizing delayed work after port events the /sys/bus/cxl/flush attribute is available for that purpose. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [djbw: clarify changelog, rework hotplug support] Link: https://lore.kernel.org/r/164398782997.903003.9725273241627693186.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
165 lines
6 KiB
Text
165 lines
6 KiB
Text
What: /sys/bus/cxl/flush
|
|
Date: Januarry, 2022
|
|
KernelVersion: v5.18
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
(WO) If userspace manually unbinds a port the kernel schedules
|
|
all descendant memdevs for unbind. Writing '1' to this attribute
|
|
flushes that work.
|
|
|
|
What: /sys/bus/cxl/devices/memX/firmware_version
|
|
Date: December, 2020
|
|
KernelVersion: v5.12
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
(RO) "FW Revision" string as reported by the Identify
|
|
Memory Device Output Payload in the CXL-2.0
|
|
specification.
|
|
|
|
What: /sys/bus/cxl/devices/memX/ram/size
|
|
Date: December, 2020
|
|
KernelVersion: v5.12
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
(RO) "Volatile Only Capacity" as bytes. Represents the
|
|
identically named field in the Identify Memory Device Output
|
|
Payload in the CXL-2.0 specification.
|
|
|
|
What: /sys/bus/cxl/devices/memX/pmem/size
|
|
Date: December, 2020
|
|
KernelVersion: v5.12
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
(RO) "Persistent Only Capacity" as bytes. Represents the
|
|
identically named field in the Identify Memory Device Output
|
|
Payload in the CXL-2.0 specification.
|
|
|
|
What: /sys/bus/cxl/devices/memX/serial
|
|
Date: January, 2022
|
|
KernelVersion: v5.18
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
(RO) 64-bit serial number per the PCIe Device Serial Number
|
|
capability. Mandatory for CXL devices, see CXL 2.0 8.1.12.2
|
|
Memory Device PCIe Capabilities and Extended Capabilities.
|
|
|
|
What: /sys/bus/cxl/devices/memX/numa_node
|
|
Date: January, 2022
|
|
KernelVersion: v5.18
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
(RO) If NUMA is enabled and the platform has affinitized the
|
|
host PCI device for this memory device, emit the CPU node
|
|
affinity for this device.
|
|
|
|
What: /sys/bus/cxl/devices/*/devtype
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
CXL device objects export the devtype attribute which mirrors
|
|
the same value communicated in the DEVTYPE environment variable
|
|
for uevents for devices on the "cxl" bus.
|
|
|
|
What: /sys/bus/cxl/devices/*/modalias
|
|
Date: December, 2021
|
|
KernelVersion: v5.18
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
CXL device objects export the modalias attribute which mirrors
|
|
the same value communicated in the MODALIAS environment variable
|
|
for uevents for devices on the "cxl" bus.
|
|
|
|
What: /sys/bus/cxl/devices/portX/uport
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
CXL port objects are enumerated from either a platform firmware
|
|
device (ACPI0017 and ACPI0016) or PCIe switch upstream port with
|
|
CXL component registers. The 'uport' symlink connects the CXL
|
|
portX object to the device that published the CXL port
|
|
capability.
|
|
|
|
What: /sys/bus/cxl/devices/portX/dportY
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
CXL port objects are enumerated from either a platform firmware
|
|
device (ACPI0017 and ACPI0016) or PCIe switch upstream port with
|
|
CXL component registers. The 'dportY' symlink identifies one or
|
|
more downstream ports that the upstream port may target in its
|
|
decode of CXL memory resources. The 'Y' integer reflects the
|
|
hardware port unique-id used in the hardware decoder target
|
|
list.
|
|
|
|
What: /sys/bus/cxl/devices/decoderX.Y
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
CXL decoder objects are enumerated from either a platform
|
|
firmware description, or a CXL HDM decoder register set in a
|
|
PCIe device (see CXL 2.0 section 8.2.5.12 CXL HDM Decoder
|
|
Capability Structure). The 'X' in decoderX.Y represents the
|
|
cxl_port container of this decoder, and 'Y' represents the
|
|
instance id of a given decoder resource.
|
|
|
|
What: /sys/bus/cxl/devices/decoderX.Y/{start,size}
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
The 'start' and 'size' attributes together convey the physical
|
|
address base and number of bytes mapped in the decoder's decode
|
|
window. For decoders of devtype "cxl_decoder_root" the address
|
|
range is fixed. For decoders of devtype "cxl_decoder_switch" the
|
|
address is bounded by the decode range of the cxl_port ancestor
|
|
of the decoder's cxl_port, and dynamically updates based on the
|
|
active memory regions in that address space.
|
|
|
|
What: /sys/bus/cxl/devices/decoderX.Y/locked
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
CXL HDM decoders have the capability to lock the configuration
|
|
until the next device reset. For decoders of devtype
|
|
"cxl_decoder_root" there is no standard facility to unlock them.
|
|
For decoders of devtype "cxl_decoder_switch" a secondary bus
|
|
reset, of the PCIe bridge that provides the bus for this
|
|
decoders uport, unlocks / resets the decoder.
|
|
|
|
What: /sys/bus/cxl/devices/decoderX.Y/target_list
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
Display a comma separated list of the current decoder target
|
|
configuration. The list is ordered by the current configured
|
|
interleave order of the decoder's dport instances. Each entry in
|
|
the list is a dport id.
|
|
|
|
What: /sys/bus/cxl/devices/decoderX.Y/cap_{pmem,ram,type2,type3}
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
When a CXL decoder is of devtype "cxl_decoder_root", it
|
|
represents a fixed memory window identified by platform
|
|
firmware. A fixed window may only support a subset of memory
|
|
types. The 'cap_*' attributes indicate whether persistent
|
|
memory, volatile memory, accelerator memory, and / or expander
|
|
memory may be mapped behind this decoder's memory window.
|
|
|
|
What: /sys/bus/cxl/devices/decoderX.Y/target_type
|
|
Date: June, 2021
|
|
KernelVersion: v5.14
|
|
Contact: linux-cxl@vger.kernel.org
|
|
Description:
|
|
When a CXL decoder is of devtype "cxl_decoder_switch", it can
|
|
optionally decode either accelerator memory (type-2) or expander
|
|
memory (type-3). The 'target_type' attribute indicates the
|
|
current setting which may dynamically change based on what
|
|
memory regions are activated in this decode hierarchy.
|