Messages in this thread | | | Date | Tue, 25 Oct 2022 11:21:43 -0700 | From | Dan Williams <> | Subject | Re: [PATCH 2/5] cxl/pci: Discover and cache pointer to RCD dport's PCIe AER capability |
| |
Terry Bowman wrote: [..] > > diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h > > index f680450f0b16..b42f4759743b 100644 > > --- a/drivers/cxl/cxl.h > > +++ b/drivers/cxl/cxl.h > > @@ -499,12 +499,19 @@ cxl_find_dport_by_dev(struct cxl_port *port, const struct device *dport_dev) > > * @port_id: unique hardware identifier for dport in decoder target list > > * @component_reg_phys: downstream port component registers > > * @port: reference to cxl_port that contains this downstream port > > + * @is_rch: enable RCH vs VH enumeration (see CXL 3.0 9.11.8) > > */ > > struct cxl_dport { > > struct device *dport; > > int port_id; > > resource_size_t component_reg_phys; > > struct cxl_port *port; > > + bool is_rch; > > +}; > > + > > +struct cxl_rch_dport { > > + struct cxl_dport dport; > > + resource_size_t rcrb_phys; > > }; > > > > The same is needed for uport as well, correct ?
Hmm, I don't think there are any 'struct cxl_port' instances that need an RCH flag in the Linux CXL topology model. That was the feedback / realization that Dave and I came to while reviewing Robert's RCH series. In the RCH case the ACPI0016 host-bridge houses a root-complex-integrated endpoint that is a peer of the downstream-PCI-root-ports in the bridge. The topology ends up looking like this:
# cxl list -BEMPTu { "bus":"root0", "provider":"ACPI.CXL", "nr_dports":1, "dports":[ { "dport":"pci0000:38", "id":"0x31" } ], "endpoints:root0":[ { "endpoint":"endpoint1", "host":"mem0", "depth":1, "memdev":{ "memdev":"mem0", "pmem_size":0, "ram_size":"16.00 GiB (17.18 GB)", "serial":"0", "numa_node":0, "host":"0000:38:00.0" } } ] }
Notice that the logical ACPI0017 (CXL root) device lists the ACPI0016 device (associated with pci0000:38) as a 'struct cxl_dport'. The endpoint is then connected to that dport. There are no intervening 'struct cxl_port' instances between the root0 and endpoint1 like there would be in the CXL VH case.
Now, the problem is that there is no viable object that can drive access to the upstream port component registers. It may be the case that when the cxl_port driver attaches to an endpoint port that the endpoint port driver maps both the upstream and downstream hardware-port registers for the purposes of conveying RAS information.
> > /** > > > > Then, when cxl_mem notices that the memdev is being produced by an > > RCIEP, it can skip devm_cxl_enumerate_ports() and jump straight to > > cxl_mem_find_port(). That will return this dport with the rcrb base > > where cxl_mem can arrange the AER handling. Likely we will need some > > notification mechanism to route Root Complex AER events to cxl_acpi, > > cxl_pci, and/or cxl_mem to optionally add the CXL RAS data to the log. > > > Isn't the notification mechanism through the AER interrupt processing? > I will have more related comments in patch 3/5.
In this case I was talking about notifying the cxl_mem driver and/or the cxl_port driver that it needs to decorate an AER event with more object-local information.
| |