Jonathan Cameron <jonathan.came...@huawei.com> writes:
> From: Ben Widawsky <ben.widaw...@intel.com> > > The CXL Early Discovery Table is defined in the CXL 2.0 specification as > a way for the OS to get CXL specific information from the system > firmware. > > CXL 2.0 specification adds an _HID, ACPI0016, for CXL capable host > bridges, with a _CID of PNP0A08 (PCIe host bridge). CXL aware software > is able to use this initiate the proper _OSC method, and get the _UID > which is referenced by the CEDT. Therefore the existence of an ACPI0016 > device allows a CXL aware driver perform the necessary actions. For a > CXL capable OS, this works. For a CXL unaware OS, this works. > > CEDT awaremess requires more. The motivation for ACPI0017 is to provide > the possibility of having a Linux CXL module that can work on a legacy > Linux kernel. Linux core PCI/ACPI which won't be built as a module, > will see the _CID of PNP0A08 and bind a driver to it. If we later loaded > a driver for ACPI0016, Linux won't be able to bind it to the hardware > because it has already bound the PNP0A08 driver. The ACPI0017 device is > an opportunity to have an object to bind a driver will be used by a > Linux driver to walk the CXL topology and do everything that we would > have preferred to do with ACPI0016. > > There is another motivation for an ACPI0017 device which isn't > implemented here. An operating system needs an attach point for a > non-volatile region provider that understands cross-hostbridge > interleaving. Since QEMU emulation doesn't support interleaving yet, > this is more important on the OS side, for now. > > As of CXL 2.0 spec, only 1 sub structure is defined, the CXL Host Bridge > Structure (CHBS) which is primarily useful for telling the OS exactly > where the MMIO for the host bridge is. > > Link: > https://lore.kernel.org/linux-cxl/20210115034911.nkgpzc756d6qm...@intel.com/T/#t > Signed-off-by: Ben Widawsky <ben.widaw...@intel.com> > Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com> Reviewed-by: Alex Bennée <alex.ben...@linaro.org> -- Alex Bennée