• Ben Widawsky's avatar
    cxl/port: Add a driver for 'struct cxl_port' objects · 54cdbf84
    Ben Widawsky authored
    The need for a CXL port driver and a dedicated cxl_bus_type is driven by
    a need to simultaneously support 2 independent physical memory decode
    domains (cache coherent CXL.mem and uncached PCI.mmio) that also
    intersect at a single PCIe device node. A CXL Port is a device that
    advertises a  CXL Component Register block with an "HDM Decoder
    Capability Structure".
    
    >From Documentation/driver-api/cxl/memory-devices.rst:
    
        Similar to how a RAID driver takes disk objects and assembles them into
        a new logical device, the CXL subsystem is tasked to take PCIe and ACPI
        objects and assemble them into a CXL.mem decode topology. The need for
        runtime configuration of the CXL.mem topology is also similar to RAID in
        that different environments with the same hardware configuration may
        decide to assemble the topology in contrasting ways. One may choose
        performance (RAID0) striping memory across multiple Host Bridges and
        endpoints while another may opt for fault tolerance and disable any
        striping in the CXL.mem topology.
    
    The port driver identifies whether an endpoint Memory Expander is
    connected to a CXL topology. If an active (bound to the 'cxl_port'
    driver) CXL Port is not found at every PCIe Switch Upstream port and an
    active "root" CXL Port then the device is just a plain PCIe endpoint
    only capable of participating in PCI.mmio and DMA cycles, not CXL.mem
    coherent interleave sets.
    
    The 'cxl_port' driver lets the CXL subsystem leverage driver-core
    infrastructure for setup and teardown of register resources and
    communicating device activation status to userspace. The cxl_bus_type
    can rendezvous the async arrival of platform level CXL resources (via
    the 'cxl_acpi' driver) with the asynchronous enumeration of Memory
    Expander endpoints, while also implementing a hierarchical locking model
    independent of the associated 'struct pci_dev' locking model. The
    locking for dport and decoder enumeration is now handled in the core
    rather than callers.
    
    For now the port driver only enumerates and registers CXL resources
    (downstream port metadata and decoder resources) later it will be used
    to take action on its decoders in response to CXL.mem region
    provisioning requests.
    
    Note1: cxlpci.h has long depended on pci.h, but port.c was the first to
    not include pci.h. Carry that dependency in cxlpci.h.
    
    Note2: cxl port enumeration and probing complicates CXL subsystem init
    to the point that it helps to have centralized debug logging of probe
    events in cxl_bus_probe().
    Reported-by: default avatarkernel test robot <lkp@intel.com>
    Signed-off-by: default avatarBen Widawsky <ben.widawsky@intel.com>
    Reviewed-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
    Co-developed-by: default avatarDan Williams <dan.j.williams@intel.com>
    Link: https://lore.kernel.org/r/164374948116.464348.1772618057599155408.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    54cdbf84
port.c 1.68 KB