On Thu, Dec 1, 2016 at 11:17 AM, Jon Masters <j...@redhat.com> wrote:
> On 12/01/2016 10:08 AM, Mark Salter wrote:
>> On Wed, 2016-11-30 at 15:42 -0800, Duc Dang wrote:
>>> +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.
> Computer Architect | Sent from my Fedora powered laptop