On Mon, May 10, 2021 at 8:23 AM Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > On Fri, 7 May 2021 15:51:58 -0700 > Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > Once the cxl_root is established then other ports in the hierarchy can > > be attached. The cxl_port object, unlike cxl_root that is associated > > with host bridges, is associated with PCIe Root Ports or PCIe Switch > > Ports. Add cxl_port instances for all PCIe Root Ports in an ACPI0016 > > host bridge. The cxl_port instances for PCIe Switch Ports are not > > included here as those are to be modeled as another service device > > registered on the pcie_port_bus_type. > > > > A sample sysfs topology for a single-host-bridge with > > single-PCIe/CXL-port follows: > > > > /sys/bus/cxl/devices/root0 > > ├── address_space0 > > │ ├── devtype > > │ ├── end > > │ ├── start > > │ ├── supports_ram > > │ ├── supports_type2 > > │ ├── supports_type3 > > │ └── uevent > > ├── address_space1 > > │ ├── devtype > > │ ├── end > > │ ├── start > > │ ├── supports_pmem > > │ ├── supports_type2 > > │ ├── supports_type3 > > │ └── uevent > > ├── devtype > > ├── port1 > > │ ├── devtype > > │ ├── host -> ../../../../LNXSYSTM:00/LNXSYBUS:00/ACPI0016:00 > > │ ├── port2 > > │ │ ├── devtype > > │ │ ├── host -> ../../../../../pci0000:34/0000:34:00.0 > > │ │ ├── subsystem -> ../../../../../../bus/cxl > > │ │ ├── target_id > > │ │ └── uevent > > │ ├── subsystem -> ../../../../../bus/cxl > > │ ├── target_id > > │ └── uevent > > ├── subsystem -> ../../../../bus/cxl > > ├── target_id > > └── uevent > > > > In this listing the system-wide-singleton root0 has 2 address spaces, 1 > > PMEM and 1 RAM. Those address spaces are accessed through port1 which > > represents the upstream port of an ACPI0016 host-bridge. A > > multi-host-bridge system would have other ports as peers to port1 to > > additionally decode root level address spaces. Port2 in this diagram > > represents the single downstream port of the host-bridge. Were it to be > > a multi-ported-host-bridge there would be peers / siblings of port2 with > > port1 as their common ancestor. > > I guess it would be a pain to emulate a system that actually had > multiple ports at the last level. Pity as would have made your > explanation here a little easier to follow. > A pain in QEMU, but maybe not with a mocked implementation similar to what gets injected for the nvdimm "nfit_test". I'll take a look. > > The rationale for this port hierarchy is to be able to walk the HDM > > decoder register sets that each port implements. Additionally it > > provides a representation of host-bridge interleave which will be > > necessary for follow-on work that adds CXL region devices. > > > > The details in the /sys/bus/cxl hierarchy that are not suitable to be > > represented in the /sys/bus/pci hierarchy are: > > - memory address spaces that are interleaved across host bridges > > - common sub-device functionality represented by CXL component + device > > registers (enumerated via DVSEC or platform firmware (ACPI CEDT)). > > I'm sold :) Thanks for the vote of confidence. It sounded like Bjorn was sold too at the end of our last thread... I'll Cc him on this patch directly in the resend. > > > > > Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> Thanks for the review Jonathan, appreciate it.
