Thread (37 messages) flat view 37 messages, 5 authors, 2017-05-16

[PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller

From: Duc Dang <hidden>
Date: 2016-12-01 19:58:45
Also in: linux-pci, lkml

On Thu, Dec 1, 2016 at 11:17 AM, Jon Masters [off-list ref] wrote:
On 12/01/2016 10:08 AM, Mark Salter wrote:
quoted
On Wed, 2016-11-30 at 15:42 -0800, Duc Dang wrote:
quoted
quoted
+static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
+{
+    struct acpi_device *adev = to_acpi_device(cfg->parent);
+    struct acpi_pci_root *root = acpi_driver_data(adev);
+    struct device *dev = cfg->parent;
+    struct xgene_pcie_port *port;
+    struct resource *csr;
+
+    port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
+    if (!port)
+            return -ENOMEM;
+
+    csr = &xgene_v1_csr_res[root->segment];
This hard-coded assumption that segment N uses controller N breaks
for m400 where segment 0 is using controller 3.
I think the latest firmware released from us a few months back use
segment 3 for PCIe controller 3 in MCFG table.
This seems very fragile. So in addition to Bjorn's comment about not
trusting firmware provided data for the segment offset in the CSR list,
you will want to also determine the controller from the ACPI tree. The
existing code walks the ACPI hierarchy and finds the CSR that way.
Obviously, the goal is to avoid that in the latest incarnation, but you
could still determine which controller matches a given device.
Yes, I will look into that more.
Jon.

--
Computer Architect | Sent from my Fedora powered laptop
Regards,
Duc Dang.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help