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

Reply via email to