Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752468AbcD2IhQ (ORCPT ); Fri, 29 Apr 2016 04:37:16 -0400 Received: from foss.arm.com ([217.140.101.70]:49225 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225AbcD2IhN (ORCPT ); Fri, 29 Apr 2016 04:37:13 -0400 Date: Fri, 29 Apr 2016 09:37:09 +0100 From: Lorenzo Pieralisi To: Bjorn Helgaas Cc: Tomasz Nowicki , arnd@arndb.de, will.deacon@arm.com, catalin.marinas@arm.com, rafael@kernel.org, hanjun.guo@linaro.org, okaya@codeaurora.org, jiang.liu@linux.intel.com, jchandra@broadcom.com, robert.richter@caviumnetworks.com, mw@semihalf.com, Liviu.Dudau@arm.com, ddaney@caviumnetworks.com, wangyijing@huawei.com, Suravee.Suthikulpanit@amd.com, msalter@redhat.com, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org, jcm@redhat.com Subject: Re: [PATCH V6 09/13] pci, acpi: Support for ACPI based generic PCI host controller Message-ID: <20160429083709.GA3249@red-moon> References: <1460740008-19489-1-git-send-email-tn@semihalf.com> <1460740008-19489-10-git-send-email-tn@semihalf.com> <20160428214800.GG25125@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160428214800.GG25125@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3196 Lines: 88 On Thu, Apr 28, 2016 at 04:48:00PM -0500, Bjorn Helgaas wrote: [...] > > +static int pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root, > > + struct acpi_pci_generic_root_info *ri) > > +{ > > + u16 seg = root->segment; > > + u8 bus_start = root->secondary.start; > > + u8 bus_end = root->secondary.end; > > + struct pci_config_window *cfg; > > + struct mcfg_entry *e; > > + phys_addr_t addr; > > + int err = 0; > > + > > + mutex_lock(&pci_mcfg_lock); > > What does this lock protect? The pci_mcfg_list should already be > initialized by the time we get there, and it should be immutable for > the life of the system. In fact, I would prefer if we could just > search the static table itself whenever we need it rather than caching > it in our own list. But I don't think we can easily do that because > acpi_table_parse() is __init. > > > + e = pci_mcfg_lookup(seg, bus_start); > > I would argue that we should check for _CBA first, and fall back to > MCFG if _CBA doesn't exist. > > > + if (!e) { > > + addr = acpi_pci_root_get_mcfg_addr(root->device->handle); > > IMO, acpi_pci_root_get_mcfg_addr() is misnamed. It should be > acpi_pci_config_base_addr() or similar. It definitely is not related > to MCFG. Not your fault, obviously. > > > + if (addr == 0) { > > + pr_err(PREFIX"%04x:%02x-%02x bus range error\n", > > + seg, bus_start, bus_end); > > + err = -ENOENT; > > + goto err_out; > > + } > > + } else { > > + if (bus_start != e->bus_start) { > > + pr_err("%04x:%02x-%02x bus range mismatch %02x\n", > > + seg, bus_start, bus_end, e->bus_start); > > + err = -EINVAL; > > + goto err_out; > > + } else if (bus_end != e->bus_end) { > > + pr_warn("%04x:%02x-%02x bus end mismatch %02x\n", > > + seg, bus_start, bus_end, e->bus_end); > > + bus_end = min(bus_end, e->bus_end); > > + } > > + addr = e->addr; > > + } > > I really don't think you need a lock around this, so you can factor > out the address lookup into something like: > > addr = acpi_pci_config_base_addr(...); > if (addr) > return addr; > > return acpi_pci_mcfg_lookup(seg, busn_res); > > You can check inside acpi_pci_mcfg_lookup() to make sure the entry you > find covers the entire [busn_res.start-busn_res.end] range and return > failure if it doesn't. At this point, I'm not sure it's worth it to > truncate the host bridge bus range to match something we find in MCFG. > > If the MCFG entry covers *more* than the host bridge range from _CRS, > that's fine. In any case, we have to be careful with the start address, > because the MCFG start address is always based on bus 0, but I think > pci_generic_ecam_create() expects the start address based on the > bus_start you pass to it. Yes, I spotted this too, it is unfortunate but DT and MCFG handle the ECAM regions differently. In DT the reg property is relative to bus_start - ie reg MMIO region maps config space starting at the first bus in bus-range: Documentation/devicetree/bindings/pci/host-generic-pci.txt in ACPI(MCFG) as you said it is always relative to bus 0, it is unfortunate but the address to be mapped should be computed differently in the ECAM layer. Lorenzo