From: Tomasz Nowicki <tomasz.nowicki@linaro.org> To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, "hanjun.guo@linaro.org" <hanjun.guo@linaro.org>, Liviu Dudau <Liviu.Dudau@arm.com>, Yijing Wang <wangyijing@huawei.com>, Will Deacon <Will.Deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>, Catalin Marinas <Catalin.Marinas@arm.com>, Jiang Liu <jiang.liu@linux.intel.com>, Thomas Gleixner <tglx@linutronix.de>, "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>, "msalter@redhat.com" <msalter@redhat.com>, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org> Subject: Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Date: Mon, 14 Sep 2015 13:34:02 +0200 [thread overview] Message-ID: <55F6B0AA.9030506@linaro.org> (raw) In-Reply-To: <20150914093719.GC18410@red-moon> On 14.09.2015 11:37, Lorenzo Pieralisi wrote: > On Fri, Sep 11, 2015 at 01:35:36PM +0100, Tomasz Nowicki wrote: >> On 11.09.2015 13:20, Lorenzo Pieralisi wrote: > > [...] > >>>>> With that in place using raw_pci_write/read or the generic accessors >>>>> becomes almost identical, with code requiring the pci_bus to be >>>>> created using the generic accessors and ACPICA using the raw version. >>>>> >>>>> I might be missing something, so apologies if that's the case. >>>>> >>>> >>>> Actually, I think you showed me the right direction :) Here are some >>>> conclusions/comments/concerns. Please correct me if I am wrong: >>>> >>>> 1. We need raw_pci_write/read accessors (based on ECAM) for ARM64 too >>>> but only up to the point where buses are enumerated. From that point on, >>>> we should reuse generic accessors from access.c file, right? >>> >>> Well, I still have not figured out whether on arm64 the raw accessors >>> required by ACPICA make sense. >>> >>> So either arm64 relies on the generic MCFG based raw read and writes >>> or we define the global raw read and writes as empty (ie x86 overrides >>> them anyway). >>> >>> I will get back to you on this. >>> >>>> 2. For ARM64 ACPI PCI, we can use generic accessors right away, .map_bus >>>> would call common code part (pci_dev_base()). The only thing that worry >>>> me is fact that MCFG regions are RCU list so it needs rcu_read_lock() >>>> for the .map_bus (mcfg lookup) *and* read/write operation. >>> >>> Do you mean the address look-up and the mmio operation should be carried >>> out atomically right ? >> Yes. > > We can wrap the calls pci_generic_read/write() within a function and > add rcu_read_lock()/unlock() around them, eg: > > int pci_generic_config_read_rcu() > { > rcu_read_lock(); > pci_generic_config_read(...); > rcu_read_unlock(); > } It looks good to me, thanks for suggestion. > > Honestly it seems the RCU API is needed just because config space > can be also accessed by raw_ accessors in ACPICA code, that's the only > reason I see to protect the config structs against config space > removal (basically config entries are removed only when the host > bridge is released if I read the code correctly, and the only way > this can happen concurrently is having ACPICA code reusing the > same config space but accessing it with no pci_bus struct attached > to it, by just using the (segment, bus, dev, fn) tuple). > Right. Side note: MCFG region can be removed from the pci_mmcfg_list list only if it has been "hot added" there. Which means that PCI host bridge specified configuration base address (_CBA) different than those from MCFG static table e.g.: DSDT.asl: Device (PCI0) { Name (_HID, EISAID ("PNP0A03")) [...] Name (_CBA, 0xB0000000) [...] } But pci_mmcfg_list elements coming from static MCFG table cannot be removed, hence they are living there for ever. Thanks, Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: tomasz.nowicki@linaro.org (Tomasz Nowicki) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Date: Mon, 14 Sep 2015 13:34:02 +0200 [thread overview] Message-ID: <55F6B0AA.9030506@linaro.org> (raw) In-Reply-To: <20150914093719.GC18410@red-moon> On 14.09.2015 11:37, Lorenzo Pieralisi wrote: > On Fri, Sep 11, 2015 at 01:35:36PM +0100, Tomasz Nowicki wrote: >> On 11.09.2015 13:20, Lorenzo Pieralisi wrote: > > [...] > >>>>> With that in place using raw_pci_write/read or the generic accessors >>>>> becomes almost identical, with code requiring the pci_bus to be >>>>> created using the generic accessors and ACPICA using the raw version. >>>>> >>>>> I might be missing something, so apologies if that's the case. >>>>> >>>> >>>> Actually, I think you showed me the right direction :) Here are some >>>> conclusions/comments/concerns. Please correct me if I am wrong: >>>> >>>> 1. We need raw_pci_write/read accessors (based on ECAM) for ARM64 too >>>> but only up to the point where buses are enumerated. From that point on, >>>> we should reuse generic accessors from access.c file, right? >>> >>> Well, I still have not figured out whether on arm64 the raw accessors >>> required by ACPICA make sense. >>> >>> So either arm64 relies on the generic MCFG based raw read and writes >>> or we define the global raw read and writes as empty (ie x86 overrides >>> them anyway). >>> >>> I will get back to you on this. >>> >>>> 2. For ARM64 ACPI PCI, we can use generic accessors right away, .map_bus >>>> would call common code part (pci_dev_base()). The only thing that worry >>>> me is fact that MCFG regions are RCU list so it needs rcu_read_lock() >>>> for the .map_bus (mcfg lookup) *and* read/write operation. >>> >>> Do you mean the address look-up and the mmio operation should be carried >>> out atomically right ? >> Yes. > > We can wrap the calls pci_generic_read/write() within a function and > add rcu_read_lock()/unlock() around them, eg: > > int pci_generic_config_read_rcu() > { > rcu_read_lock(); > pci_generic_config_read(...); > rcu_read_unlock(); > } It looks good to me, thanks for suggestion. > > Honestly it seems the RCU API is needed just because config space > can be also accessed by raw_ accessors in ACPICA code, that's the only > reason I see to protect the config structs against config space > removal (basically config entries are removed only when the host > bridge is released if I read the code correctly, and the only way > this can happen concurrently is having ACPICA code reusing the > same config space but accessing it with no pci_bus struct attached > to it, by just using the (segment, bus, dev, fn) tuple). > Right. Side note: MCFG region can be removed from the pci_mmcfg_list list only if it has been "hot added" there. Which means that PCI host bridge specified configuration base address (_CBA) different than those from MCFG static table e.g.: DSDT.asl: Device (PCI0) { Name (_HID, EISAID ("PNP0A03")) [...] Name (_CBA, 0xB0000000) [...] } But pci_mmcfg_list elements coming from static MCFG table cannot be removed, hence they are living there for ever. Thanks, Tomasz
next prev parent reply other threads:[~2015-09-14 11:34 UTC|newest] Thread overview: 175+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-26 12:49 [PATCH 00/11] ARM64 PCI hostbridge init based on ACPI Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` [PATCH 01/11] ARM64 / PCI: introduce struct pci_controller for ACPI Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 16:58 ` Liviu Dudau 2015-05-26 16:58 ` Liviu Dudau 2015-05-26 16:58 ` Liviu Dudau 2015-05-26 16:58 ` Liviu Dudau 2015-05-26 17:20 ` Jiang Liu 2015-05-26 17:20 ` Jiang Liu 2015-05-26 17:20 ` Jiang Liu 2015-05-27 8:21 ` Hanjun Guo 2015-05-27 8:21 ` Hanjun Guo 2015-05-27 8:21 ` Hanjun Guo 2015-09-07 4:14 ` Ganapatrao Kulkarni 2015-09-07 4:14 ` Ganapatrao Kulkarni 2015-09-07 4:14 ` Ganapatrao Kulkarni 2015-09-07 8:45 ` Lorenzo Pieralisi 2015-09-07 8:45 ` Lorenzo Pieralisi 2015-09-07 8:45 ` Lorenzo Pieralisi 2015-09-08 13:35 ` Hanjun Guo 2015-09-08 13:35 ` Hanjun Guo 2015-09-08 13:35 ` Hanjun Guo 2015-05-27 9:47 ` Liviu Dudau 2015-05-27 9:47 ` Liviu Dudau 2015-05-27 9:47 ` Liviu Dudau 2015-05-27 9:47 ` Liviu Dudau 2015-05-27 11:29 ` Jiang Liu 2015-05-27 11:29 ` Jiang Liu 2015-05-27 11:29 ` Jiang Liu 2015-05-26 12:49 ` [PATCH 02/11] x86, pci: Clean up comment about buggy MMIO config space access for AMD Fam10h CPUs Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-08-31 12:04 ` Tomasz Nowicki 2015-08-31 12:04 ` Tomasz Nowicki 2015-05-26 12:49 ` [PATCH 03/11] x86, pci: Abstract PCI config accessors and use AMD Fam10h workaround exclusively Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` [PATCH 04/11] x86, pci: Reorder logic of pci_mmconfig_insert() function Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 17:08 ` Will Deacon 2015-05-26 17:08 ` Will Deacon 2015-05-26 17:08 ` Will Deacon 2015-05-27 8:06 ` Tomasz Nowicki 2015-05-27 8:06 ` Tomasz Nowicki 2015-05-27 8:06 ` Tomasz Nowicki 2015-06-02 13:32 ` Lorenzo Pieralisi 2015-06-02 13:32 ` Lorenzo Pieralisi 2015-06-02 13:32 ` Lorenzo Pieralisi 2015-06-04 9:28 ` Hanjun Guo 2015-06-04 9:28 ` Hanjun Guo 2015-06-04 9:28 ` Hanjun Guo 2015-06-04 10:22 ` Lorenzo Pieralisi 2015-06-04 10:22 ` Lorenzo Pieralisi 2015-06-04 10:22 ` Lorenzo Pieralisi 2015-06-04 12:28 ` Hanjun Guo 2015-06-04 12:28 ` Hanjun Guo 2015-06-04 12:28 ` Hanjun Guo 2015-06-04 12:28 ` Hanjun Guo 2015-06-08 2:57 ` Hanjun Guo 2015-06-08 2:57 ` Hanjun Guo 2015-06-08 2:57 ` Hanjun Guo 2015-06-08 2:57 ` Hanjun Guo 2015-06-08 15:14 ` Lorenzo Pieralisi 2015-06-08 15:14 ` Lorenzo Pieralisi 2015-06-08 15:14 ` Lorenzo Pieralisi 2015-08-31 11:01 ` Tomasz Nowicki 2015-08-31 11:01 ` Tomasz Nowicki 2015-08-31 11:01 ` Tomasz Nowicki 2015-09-07 9:59 ` Tomasz Nowicki 2015-09-07 9:59 ` Tomasz Nowicki 2015-09-07 9:59 ` Tomasz Nowicki 2015-09-08 15:07 ` Lorenzo Pieralisi 2015-09-08 15:07 ` Lorenzo Pieralisi 2015-09-08 15:07 ` Lorenzo Pieralisi 2015-09-09 13:47 ` Tomasz Nowicki 2015-09-09 13:47 ` Tomasz Nowicki 2015-09-09 13:47 ` Tomasz Nowicki 2015-09-09 13:47 ` Tomasz Nowicki 2015-09-11 11:20 ` Lorenzo Pieralisi 2015-09-11 11:20 ` Lorenzo Pieralisi 2015-09-11 11:20 ` Lorenzo Pieralisi 2015-09-11 12:35 ` Tomasz Nowicki 2015-09-11 12:35 ` Tomasz Nowicki 2015-09-11 12:35 ` Tomasz Nowicki 2015-09-14 9:37 ` Lorenzo Pieralisi 2015-09-14 9:37 ` Lorenzo Pieralisi 2015-09-14 9:37 ` Lorenzo Pieralisi 2015-09-14 11:34 ` Tomasz Nowicki [this message] 2015-09-14 11:34 ` Tomasz Nowicki 2015-09-14 11:34 ` Tomasz Nowicki 2015-09-14 14:55 ` Tomasz Nowicki 2015-09-14 14:55 ` Tomasz Nowicki 2015-09-14 14:55 ` Tomasz Nowicki 2015-09-25 16:02 ` Tomasz Nowicki 2015-09-25 16:02 ` Tomasz Nowicki 2015-09-25 16:02 ` Tomasz Nowicki 2015-09-25 16:19 ` Lorenzo Pieralisi 2015-09-25 16:19 ` Lorenzo Pieralisi 2015-09-25 16:19 ` Lorenzo Pieralisi 2015-10-15 13:22 ` Lorenzo Pieralisi 2015-10-15 13:22 ` Lorenzo Pieralisi 2015-10-15 13:22 ` Lorenzo Pieralisi 2015-10-15 14:34 ` Tomasz Nowicki 2015-10-15 14:34 ` Tomasz Nowicki 2015-10-15 14:34 ` Tomasz Nowicki 2015-10-15 16:26 ` Marc Zyngier 2015-10-15 16:26 ` Marc Zyngier 2015-10-15 16:26 ` Marc Zyngier 2015-10-15 18:51 ` Tomasz Nowicki 2015-10-15 18:51 ` Tomasz Nowicki 2015-10-15 18:51 ` Tomasz Nowicki 2015-05-26 12:49 ` [PATCH 06/11] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` [PATCH 07/11] x86, pci: mmconfig_{32, 64}.c code refactoring - remove code duplication Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` [PATCH 07/11] x86, pci: mmconfig_{32,64}.c " Hanjun Guo 2015-05-26 12:49 ` [PATCH 08/11] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` [PATCH 09/11] pci, acpi, mcfg: Share ACPI PCI config space accessors Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` [PATCH 10/11] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 13:54 ` Boris Ostrovsky 2015-05-26 13:54 ` Boris Ostrovsky 2015-05-26 14:00 ` Boris Ostrovsky 2015-05-26 14:00 ` Boris Ostrovsky 2015-05-26 14:54 ` Tomasz Nowicki 2015-05-26 14:54 ` Tomasz Nowicki 2015-05-26 15:44 ` Boris Ostrovsky 2015-05-26 15:44 ` Boris Ostrovsky 2015-05-27 3:55 ` Hanjun Guo 2015-05-27 3:55 ` Hanjun Guo 2015-05-26 12:49 ` [PATCH 11/11] ARM64 / PCI / ACPI: support for ACPI based PCI hostbridge init Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 12:49 ` Hanjun Guo 2015-05-26 15:12 ` Tomasz Nowicki 2015-05-26 15:12 ` Tomasz Nowicki 2015-05-27 7:31 ` Hanjun Guo 2015-05-27 7:31 ` Hanjun Guo 2015-05-27 7:31 ` Hanjun Guo 2015-05-26 17:13 ` Will Deacon 2015-05-26 17:13 ` Will Deacon 2015-05-26 17:13 ` Will Deacon 2015-05-26 17:24 ` Jiang Liu 2015-05-26 17:24 ` Jiang Liu 2015-05-26 17:24 ` Jiang Liu 2015-05-27 0:30 ` [PATCH 00/11] ARM64 PCI hostbridge init based on ACPI Rafael J. Wysocki 2015-05-27 0:30 ` Rafael J. Wysocki 2015-05-27 3:57 ` Hanjun Guo 2015-05-27 3:57 ` Hanjun Guo 2015-06-08 12:05 ` Jagan Teki 2015-06-08 12:05 ` Jagan Teki 2015-06-08 12:05 ` Jagan Teki 2015-06-10 2:47 ` Hanjun Guo 2015-06-10 2:47 ` Hanjun Guo 2015-06-10 2:47 ` Hanjun Guo 2015-10-15 19:15 ` Jon Masters 2015-10-15 19:15 ` Jon Masters 2015-10-15 23:42 ` Hanjun Guo 2015-10-15 23:42 ` Hanjun Guo 2015-10-15 23:49 ` Jon Masters 2015-10-15 23:49 ` Jon Masters 2015-12-07 20:29 ` Bjorn Helgaas 2015-12-07 20:29 ` Bjorn Helgaas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=55F6B0AA.9030506@linaro.org \ --to=tomasz.nowicki@linaro.org \ --cc=Catalin.Marinas@arm.com \ --cc=Liviu.Dudau@arm.com \ --cc=Will.Deacon@arm.com \ --cc=arnd@arndb.de \ --cc=bhelgaas@google.com \ --cc=hanjun.guo@linaro.org \ --cc=jiang.liu@linux.intel.com \ --cc=linaro-acpi@lists.linaro.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=msalter@redhat.com \ --cc=rjw@rjwysocki.net \ --cc=suravee.suthikulpanit@amd.com \ --cc=tglx@linutronix.de \ --cc=wangyijing@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.