From: Yijing Wang <wangyijing@huawei.com>
To: Liviu Dudau <liviu@dudau.co.uk>,
Tomasz Nowicki <tomasz.nowicki@linaro.org>
Cc: Tony Luck <tony.luck@intel.com>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
linux-pci@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, Xinwei Hu <huxinwei@huawei.com>,
Thierry Reding <thierry.reding@gmail.com>,
Suravee.Suthikulpanit@amd.com,
Bjorn Helgaas <bhelgaas@google.com>,
linux-ia64@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Wuyun <wuyun.wu@huawei.com>,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 00/16] Refine PCI host bridge scan interfaces
Date: Fri, 21 Nov 2014 10:58:24 +0800 [thread overview]
Message-ID: <546EAA50.8000601@huawei.com> (raw)
In-Reply-To: <20141120163918.GE9162@bart.dudau.co.uk>
On 2014/11/21 0:39, Liviu Dudau wrote:
> On Thu, Nov 20, 2014 at 01:53:48PM +0100, Tomasz Nowicki wrote:
>> On 20.11.2014 13:08, Liviu Dudau wrote:
>>> On Thu, Nov 20, 2014 at 12:54:48PM +0100, Tomasz Nowicki wrote:
>>>> On 17.11.2014 15:13, Arnd Bergmann wrote:
>>>>> On Monday 17 November 2014 18:21:34 Yijing Wang wrote:
>>>>>> This series is based Linux 3.18-rc1 and Lorenzo Pieralisi's
>>>>>> arm PCI domain cleanup patches, link:
>>>>>> https://patchwork.ozlabs.org/patch/407585/
>>>>>>
>>>>>> Current pci scan interfaces like pci_scan_root_bus() and directly
>>>>>> call pci_create_root_bus()/pci_scan_child_bus() lack flexiblity.
>>>>>> Some platform infos like PCI domain and msi_chip have to be
>>>>>> associated to PCI bus by some arch specific function.
>>>>>> We want to make a generic pci_host_bridge, and make it hold
>>>>>> the platform infos or hook. Then we could eliminate the lots
>>>>>> of arch pci_domain_nr, also we could associate some platform
>>>>>> ops something like pci_get_msi_chip(struct pci_dev *dev)
>>>>>> with pci_host_bridge to avoid introduce arch weak functions.
>>>>>>
>>>>>> This RFC version not for all platforms, just applied the new
>>>>>> scan interface in x86/arm/powerpc/ia64, I will refresh other
>>>>>> platforms after the core pci scan interfaces are ok.
>>>>>
>>>>> I think overall this is a good direction to take, in particular
>>>>> moving more things into struct pci_host_bridge so we can
>>>>> slim down the architecture specific code.
>>>>>
>>>>> I don't particularly like the way you use the 'pci_host_info'
>>>>> to pass callback pointers and some of the generic information.
>>>>> This duplicates some of the issues we are currently trying
>>>>> to untangle in the arm32 code to make drivers easier to share
>>>>> between architectures.
>>>>>
>>>>> As a general approach, I'd rather see generic helper functions
>>>>> being exported by the PCI core that a driver may or may not
>>>>> call.
>>>>> The way you split the interface between things that happen
>>>>> before scanning the buses (pci_create_host_bridge) and
>>>>> the actual scanning (__pci_create_root_bus, pci_scan_child_bus)
>>>>> seems very helpful and I think we can expand that concept further:
>>>>>
>>>>> - The normal pci_create_host_bridge() function can contain
>>>>> all of the DT scanning functions (finding bus/mem/io resources,
>>>>> finding the msi-parent), while drivers that don't depend on DT
>>>>> for this information can call the same function and fill the
>>>>> same things after they have the pci_host_bridge pointer.
>>>>
>>>> How about finding PCI domain number (in the DT way) within
>>>> pci_create_host_bridge() too ?
>>>
>>> It is an idea worth pursuing for the 99% of the cases. I would like
>>> to understand the 1% of the time when we want a domain number to be
>>> shared between two host bridges or the time when we want more than
>>> one domain per bridge.
>> Even though we have shared domain, this should be resolved via DT calls, do
>> I miss something ?
>
> If we only going to hold one domain number per host bridge, then no, you're
> not missing anything.
>
>>
>>>
>>> Is that possible? Is it useful? Is it already in practice?
>> This is good question... IMO:
>> 1. Two host bridges can shared domain number if they are children of the
>> same parent host bridge.
>> 2. But I can not find good explanation for more than one domain per bridge.
>
> Splitting a root bus into two or more "segments" ?
It seems impossible.
>
> Best regards,
> Liviu
>
>>
>> Tomasz
>>
>>
>
--
Thanks!
Yijing
prev parent reply other threads:[~2014-11-21 2:58 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 10:21 [RFC PATCH 00/16] Refine PCI host bridge scan interfaces Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources Yijing Wang
2014-11-17 10:08 ` Arnd Bergmann
2014-11-18 7:44 ` Yijing Wang
2014-11-18 9:36 ` Arnd Bergmann
2014-11-18 11:46 ` Yijing Wang
2014-11-18 14:23 ` Liviu Dudau
2014-11-19 1:15 ` Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 02/16] PCI: Use pci_scan_root_bus() instead of pci_scan_bus() Yijing Wang
2014-11-18 14:28 ` Liviu Dudau
2014-11-19 1:19 ` Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 03/16] PCI: Clean up pci_scan_bus() Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 04/16] PCI: Rip out pci_bus_add_devices() from pci_scan_root_bus() Yijing Wang
2014-11-18 14:34 ` Liviu Dudau
2014-11-19 1:21 ` Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 05/16] PCI: Use pci_scan_root_bus() instead of pci_scan_bus_parented() Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 06/16] PCI: Use u32 type to combine PCI domain and bus number Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus() Yijing Wang
2014-11-17 10:56 ` Arnd Bergmann
2014-11-18 8:32 ` Yijing Wang
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 11:44 ` Yijing Wang
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:41 ` Yijing Wang
2014-11-18 14:48 ` Liviu Dudau
2014-11-19 2:24 ` Yijing Wang
2014-11-19 16:29 ` Liviu Dudau
2014-11-20 2:00 ` Yijing Wang
2014-11-18 15:30 ` Liviu Dudau
2014-11-19 1:42 ` Yijing Wang
2014-11-19 16:37 ` Liviu Dudau
2014-11-20 2:47 ` Yijing Wang
2014-11-20 9:47 ` Liviu Dudau
2014-11-21 2:53 ` Yijing Wang
2014-11-21 9:53 ` Liviu Dudau
2014-11-17 10:21 ` [RFC PATCH 08/16] PCI: Introduce pci_scan_host_bridge() and pci_host_info Yijing Wang
2014-11-18 15:42 ` Liviu Dudau
2014-11-19 2:09 ` Yijing Wang
2014-11-19 16:41 ` Liviu Dudau
2014-11-20 2:54 ` Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 09/16] PCI: Associate .get_msi_ctrl() with pci_host_bridge Yijing Wang
2014-11-17 15:03 ` Lorenzo Pieralisi
2014-11-17 10:21 ` [RFC PATCH 10/16] PCI: Add of_scan_bus() to pci_host_info Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 11/16] x86/PCI: Use pci_scan_host_bridge() instead of pci_create_root_bus() Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 12/16] ia64/PCI: Remove the redundant bus variable Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 13/16] ia64/PCI: Use pci_scan_host_bridge() to refactor pci_acpi_scan_root() Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 14/16] arm/PCI: Introduce pci_get_domain_nr() Yijing Wang
2014-11-17 12:08 ` Lorenzo Pieralisi
2014-11-18 0:55 ` Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 15/16] arm/PCI: Use pci_scan_host_bridge() instead of pci_scan_root_bus() Yijing Wang
2014-11-17 10:21 ` [RFC PATCH 16/16] powerpc/PCI: Use pci_scan_host_bridge() to scan PCI bus Yijing Wang
2014-11-17 14:13 ` [RFC PATCH 00/16] Refine PCI host bridge scan interfaces Arnd Bergmann
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:45 ` Lorenzo Pieralisi
2014-11-18 12:14 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:27 ` Arnd Bergmann
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 12:08 ` Liviu Dudau
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 16:39 ` Liviu Dudau
2014-11-21 2:58 ` Yijing Wang [this message]
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=546EAA50.8000601@huawei.com \
--to=wangyijing@huawei.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=huxinwei@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=liviu@dudau.co.uk \
--cc=tglx@linutronix.de \
--cc=thierry.reding@gmail.com \
--cc=tomasz.nowicki@linaro.org \
--cc=tony.luck@intel.com \
--cc=wuyun.wu@huawei.com \
--cc=x86@kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).