From: Yijing Wang <wangyijing@huawei.com>
To: Liviu Dudau <liviu@dudau.co.uk>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>, Arnd Bergmann <arnd@arndb.de>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Tony Luck <tony.luck@intel.com>,
Russell King <linux@arm.linux.org.uk>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"huxinwei@huawei.com" <huxinwei@huawei.com>,
Thierry Reding <thierry.reding@gmail.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>, Wuyun <wuyun.wu@huawei.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
Date: Thu, 20 Nov 2014 02:00:41 +0000 [thread overview]
Message-ID: <546D4B49.6020408@huawei.com> (raw)
In-Reply-To: <20141119162914.GB9162@bart.dudau.co.uk>
>>> Something like this:
>>>
>>> struct pci_controller {
>>> struct pci_host_bridge bridge;
>>> /* private host bridge data here */
>>> .....
>>> };
>>>
>>> #define PCI_CONTROLLER(bus) ({
>>> struct pci_host_bridge *hb = to_pci_host_bridge(bus->bridge); \
>>> container_of(hb, struct pci_controller, bridge); })
>>>
>>>
>>> Then we can retrieve the host bridge structure from everywhere we have a device.
>>
>> Hi Liviu, it looks good to me, because this change will involve lots platforms,
>> I would think more about it. Thanks for your suggestion very much! :)
>
> Given that I also look at this area maybe we should join forces and divide the problem?
That's better, we could cooperate to do this. :)
>
> Best regards,
> Liviu
>
>>
>>
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>>> + host = kzalloc(sizeof(*host), GFP_KERNEL);
>>>>>> + if (!host)
>>>>>> + return NULL;
>>>>>
>>>>> devm_kzalloc maybe?
>>>>
>>>> I don't know much detail about devm_kzalloc(), but we have no pci host driver
>>>> here, and I found no devm_kzalloc() uses in core PCI code before.
>>>>
>>>>>
>>>>>> + if (!resources) {
>>>>>> + /* Use default IO/MEM/BUS resources*/
>>>>>> + pci_add_resource(&host->windows, &ioport_resource);
>>>>>> + pci_add_resource(&host->windows, &iomem_resource);
>>>>>> + pci_add_resource(&host->windows, &busn_resource);
>>>>>> + } else {
>>>>>> + list_for_each_entry_safe(window, n, resources, list)
>>>>>> + list_move_tail(&window->list, &host->windows);
>>>>>> + }
>>>>>
>>>>> I think we should assume that the correct resources are passed. You
>>>>> could add a wrapper around this function to convert old platforms
>>>>> though.
>>>>
>>>> OK, I will move these code out of pci_create_host_bridge, and add a wrapper
>>>> to setup the default resources.
>>>>
>>>>>
>>>>>> +EXPORT_SYMBOL(pci_create_host_bridge);
>>>>>
>>>>> EXPORT_SYMBOL_GPL() maybe?
>>>>
>>>> OK, will update it.
>>>>
>>>>>
>>>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>>>> index 8b11b38..daa7f40 100644
>>>>>> --- a/include/linux/pci.h
>>>>>> +++ b/include/linux/pci.h
>>>>>> @@ -402,7 +402,12 @@ struct pci_host_bridge_window {
>>>>>> struct pci_host_bridge {
>>>>>> struct device dev;
>>>>>> struct pci_bus *bus; /* root bus */
>>>>>> + struct list_head list;
>>>>>> struct list_head windows; /* pci_host_bridge_windows */
>>>>>> + int busnum;
>>>>>
>>>>> The busnum should already be implied through the bus resource.
>>>>
>>>> Yes, I will consider remove it and introduce a helper function to get the root bus number, thanks!
>>>>
>>>> Thanks!
>>>> Yijing.
>>>>
>>>>>
>>>>> Arnd
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks!
>>>> Yijing
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
Thanks!
Yijing
WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com>
To: Liviu Dudau <liviu@dudau.co.uk>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>, Arnd Bergmann <arnd@arndb.de>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
Tony Luck <tony.luck@intel.com>,
Russell King <linux@arm.linux.org.uk>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"huxinwei@huawei.com" <huxinwei@huawei.com>,
Thierry Reding <thierry.reding@gmail.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>, Wuyun <wuyun.wu@huawei.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
Date: Thu, 20 Nov 2014 10:00:41 +0800 [thread overview]
Message-ID: <546D4B49.6020408@huawei.com> (raw)
In-Reply-To: <20141119162914.GB9162@bart.dudau.co.uk>
>>> Something like this:
>>>
>>> struct pci_controller {
>>> struct pci_host_bridge bridge;
>>> /* private host bridge data here */
>>> .....
>>> };
>>>
>>> #define PCI_CONTROLLER(bus) ({
>>> struct pci_host_bridge *hb = to_pci_host_bridge(bus->bridge); \
>>> container_of(hb, struct pci_controller, bridge); })
>>>
>>>
>>> Then we can retrieve the host bridge structure from everywhere we have a device.
>>
>> Hi Liviu, it looks good to me, because this change will involve lots platforms,
>> I would think more about it. Thanks for your suggestion very much! :)
>
> Given that I also look at this area maybe we should join forces and divide the problem?
That's better, we could cooperate to do this. :)
>
> Best regards,
> Liviu
>
>>
>>
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>>> + host = kzalloc(sizeof(*host), GFP_KERNEL);
>>>>>> + if (!host)
>>>>>> + return NULL;
>>>>>
>>>>> devm_kzalloc maybe?
>>>>
>>>> I don't know much detail about devm_kzalloc(), but we have no pci host driver
>>>> here, and I found no devm_kzalloc() uses in core PCI code before.
>>>>
>>>>>
>>>>>> + if (!resources) {
>>>>>> + /* Use default IO/MEM/BUS resources*/
>>>>>> + pci_add_resource(&host->windows, &ioport_resource);
>>>>>> + pci_add_resource(&host->windows, &iomem_resource);
>>>>>> + pci_add_resource(&host->windows, &busn_resource);
>>>>>> + } else {
>>>>>> + list_for_each_entry_safe(window, n, resources, list)
>>>>>> + list_move_tail(&window->list, &host->windows);
>>>>>> + }
>>>>>
>>>>> I think we should assume that the correct resources are passed. You
>>>>> could add a wrapper around this function to convert old platforms
>>>>> though.
>>>>
>>>> OK, I will move these code out of pci_create_host_bridge, and add a wrapper
>>>> to setup the default resources.
>>>>
>>>>>
>>>>>> +EXPORT_SYMBOL(pci_create_host_bridge);
>>>>>
>>>>> EXPORT_SYMBOL_GPL() maybe?
>>>>
>>>> OK, will update it.
>>>>
>>>>>
>>>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>>>> index 8b11b38..daa7f40 100644
>>>>>> --- a/include/linux/pci.h
>>>>>> +++ b/include/linux/pci.h
>>>>>> @@ -402,7 +402,12 @@ struct pci_host_bridge_window {
>>>>>> struct pci_host_bridge {
>>>>>> struct device dev;
>>>>>> struct pci_bus *bus; /* root bus */
>>>>>> + struct list_head list;
>>>>>> struct list_head windows; /* pci_host_bridge_windows */
>>>>>> + int busnum;
>>>>>
>>>>> The busnum should already be implied through the bus resource.
>>>>
>>>> Yes, I will consider remove it and introduce a helper function to get the root bus number, thanks!
>>>>
>>>> Thanks!
>>>> Yijing.
>>>>
>>>>>
>>>>> Arnd
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks!
>>>> Yijing
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
Thanks!
Yijing
WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com>
To: Liviu Dudau <liviu@dudau.co.uk>
Cc: Tony Luck <tony.luck@intel.com>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Liviu Dudau <Liviu.Dudau@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"huxinwei@huawei.com" <huxinwei@huawei.com>,
Thierry Reding <thierry.reding@gmail.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>, Wuyun <wuyun.wu@huawei.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
Date: Thu, 20 Nov 2014 10:00:41 +0800 [thread overview]
Message-ID: <546D4B49.6020408@huawei.com> (raw)
In-Reply-To: <20141119162914.GB9162@bart.dudau.co.uk>
>>> Something like this:
>>>
>>> struct pci_controller {
>>> struct pci_host_bridge bridge;
>>> /* private host bridge data here */
>>> .....
>>> };
>>>
>>> #define PCI_CONTROLLER(bus) ({
>>> struct pci_host_bridge *hb = to_pci_host_bridge(bus->bridge); \
>>> container_of(hb, struct pci_controller, bridge); })
>>>
>>>
>>> Then we can retrieve the host bridge structure from everywhere we have a device.
>>
>> Hi Liviu, it looks good to me, because this change will involve lots platforms,
>> I would think more about it. Thanks for your suggestion very much! :)
>
> Given that I also look at this area maybe we should join forces and divide the problem?
That's better, we could cooperate to do this. :)
>
> Best regards,
> Liviu
>
>>
>>
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>>> + host = kzalloc(sizeof(*host), GFP_KERNEL);
>>>>>> + if (!host)
>>>>>> + return NULL;
>>>>>
>>>>> devm_kzalloc maybe?
>>>>
>>>> I don't know much detail about devm_kzalloc(), but we have no pci host driver
>>>> here, and I found no devm_kzalloc() uses in core PCI code before.
>>>>
>>>>>
>>>>>> + if (!resources) {
>>>>>> + /* Use default IO/MEM/BUS resources*/
>>>>>> + pci_add_resource(&host->windows, &ioport_resource);
>>>>>> + pci_add_resource(&host->windows, &iomem_resource);
>>>>>> + pci_add_resource(&host->windows, &busn_resource);
>>>>>> + } else {
>>>>>> + list_for_each_entry_safe(window, n, resources, list)
>>>>>> + list_move_tail(&window->list, &host->windows);
>>>>>> + }
>>>>>
>>>>> I think we should assume that the correct resources are passed. You
>>>>> could add a wrapper around this function to convert old platforms
>>>>> though.
>>>>
>>>> OK, I will move these code out of pci_create_host_bridge, and add a wrapper
>>>> to setup the default resources.
>>>>
>>>>>
>>>>>> +EXPORT_SYMBOL(pci_create_host_bridge);
>>>>>
>>>>> EXPORT_SYMBOL_GPL() maybe?
>>>>
>>>> OK, will update it.
>>>>
>>>>>
>>>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>>>> index 8b11b38..daa7f40 100644
>>>>>> --- a/include/linux/pci.h
>>>>>> +++ b/include/linux/pci.h
>>>>>> @@ -402,7 +402,12 @@ struct pci_host_bridge_window {
>>>>>> struct pci_host_bridge {
>>>>>> struct device dev;
>>>>>> struct pci_bus *bus; /* root bus */
>>>>>> + struct list_head list;
>>>>>> struct list_head windows; /* pci_host_bridge_windows */
>>>>>> + int busnum;
>>>>>
>>>>> The busnum should already be implied through the bus resource.
>>>>
>>>> Yes, I will consider remove it and introduce a helper function to get the root bus number, thanks!
>>>>
>>>> Thanks!
>>>> Yijing.
>>>>
>>>>>
>>>>> Arnd
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks!
>>>> Yijing
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
Thanks!
Yijing
WARNING: multiple messages have this Message-ID (diff)
From: wangyijing@huawei.com (Yijing Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
Date: Thu, 20 Nov 2014 10:00:41 +0800 [thread overview]
Message-ID: <546D4B49.6020408@huawei.com> (raw)
In-Reply-To: <20141119162914.GB9162@bart.dudau.co.uk>
>>> Something like this:
>>>
>>> struct pci_controller {
>>> struct pci_host_bridge bridge;
>>> /* private host bridge data here */
>>> .....
>>> };
>>>
>>> #define PCI_CONTROLLER(bus) ({
>>> struct pci_host_bridge *hb = to_pci_host_bridge(bus->bridge); \
>>> container_of(hb, struct pci_controller, bridge); })
>>>
>>>
>>> Then we can retrieve the host bridge structure from everywhere we have a device.
>>
>> Hi Liviu, it looks good to me, because this change will involve lots platforms,
>> I would think more about it. Thanks for your suggestion very much! :)
>
> Given that I also look at this area maybe we should join forces and divide the problem?
That's better, we could cooperate to do this. :)
>
> Best regards,
> Liviu
>
>>
>>
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>>> + host = kzalloc(sizeof(*host), GFP_KERNEL);
>>>>>> + if (!host)
>>>>>> + return NULL;
>>>>>
>>>>> devm_kzalloc maybe?
>>>>
>>>> I don't know much detail about devm_kzalloc(), but we have no pci host driver
>>>> here, and I found no devm_kzalloc() uses in core PCI code before.
>>>>
>>>>>
>>>>>> + if (!resources) {
>>>>>> + /* Use default IO/MEM/BUS resources*/
>>>>>> + pci_add_resource(&host->windows, &ioport_resource);
>>>>>> + pci_add_resource(&host->windows, &iomem_resource);
>>>>>> + pci_add_resource(&host->windows, &busn_resource);
>>>>>> + } else {
>>>>>> + list_for_each_entry_safe(window, n, resources, list)
>>>>>> + list_move_tail(&window->list, &host->windows);
>>>>>> + }
>>>>>
>>>>> I think we should assume that the correct resources are passed. You
>>>>> could add a wrapper around this function to convert old platforms
>>>>> though.
>>>>
>>>> OK, I will move these code out of pci_create_host_bridge, and add a wrapper
>>>> to setup the default resources.
>>>>
>>>>>
>>>>>> +EXPORT_SYMBOL(pci_create_host_bridge);
>>>>>
>>>>> EXPORT_SYMBOL_GPL() maybe?
>>>>
>>>> OK, will update it.
>>>>
>>>>>
>>>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>>>> index 8b11b38..daa7f40 100644
>>>>>> --- a/include/linux/pci.h
>>>>>> +++ b/include/linux/pci.h
>>>>>> @@ -402,7 +402,12 @@ struct pci_host_bridge_window {
>>>>>> struct pci_host_bridge {
>>>>>> struct device dev;
>>>>>> struct pci_bus *bus; /* root bus */
>>>>>> + struct list_head list;
>>>>>> struct list_head windows; /* pci_host_bridge_windows */
>>>>>> + int busnum;
>>>>>
>>>>> The busnum should already be implied through the bus resource.
>>>>
>>>> Yes, I will consider remove it and introduce a helper function to get the root bus number, thanks!
>>>>
>>>> Thanks!
>>>> Yijing.
>>>>
>>>>>
>>>>> Arnd
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks!
>>>> Yijing
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
Thanks!
Yijing
next prev parent reply other threads:[~2014-11-20 2:00 UTC|newest]
Thread overview: 253+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 9:43 [RFC PATCH 00/16] Refine PCI host bridge scan interfaces Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:40 ` [RFC PATCH 03/16] PCI: Clean up pci_scan_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:40 ` [RFC PATCH 12/16] ia64/PCI: Remove the redundant bus variable Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:40 ` [RFC PATCH 05/16] PCI: Use pci_scan_root_bus() instead of pci_scan_bus_parented() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:42 ` [RFC PATCH 16/16] powerpc/PCI: Use pci_scan_host_bridge() to scan PCI bus Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 15/16] arm/PCI: Use pci_scan_host_bridge() instead of pci_scan_root_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 14/16] arm/PCI: Introduce pci_get_domain_nr() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 12:08 ` Lorenzo Pieralisi
2014-11-17 12:08 ` Lorenzo Pieralisi
2014-11-17 12:08 ` Lorenzo Pieralisi
2014-11-18 0:55 ` Yijing Wang
2014-11-18 0:55 ` Yijing Wang
2014-11-18 0:55 ` Yijing Wang
2014-11-18 0:55 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 13/16] ia64/PCI: Use pci_scan_host_bridge() to refactor pci_acpi_scan_root() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 09/16] PCI: Associate .get_msi_ctrl() with pci_host_bridge Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 15:03 ` Lorenzo Pieralisi
2014-11-17 15:03 ` Lorenzo Pieralisi
2014-11-17 15:03 ` Lorenzo Pieralisi
2014-11-17 9:43 ` [RFC PATCH 10/16] PCI: Add of_scan_bus() to pci_host_info Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 04/16] PCI: Rip out pci_bus_add_devices() from pci_scan_root_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-18 14:34 ` Liviu Dudau
2014-11-18 14:34 ` Liviu Dudau
2014-11-18 14:34 ` Liviu Dudau
2014-11-18 14:34 ` Liviu Dudau
2014-11-19 1:21 ` Yijing Wang
2014-11-19 1:21 ` Yijing Wang
2014-11-19 1:21 ` Yijing Wang
2014-11-19 1:21 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 06/16] PCI: Use u32 type to combine PCI domain and bus number Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 02/16] PCI: Use pci_scan_root_bus() instead of pci_scan_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-18 14:28 ` Liviu Dudau
2014-11-18 14:28 ` Liviu Dudau
2014-11-18 14:28 ` Liviu Dudau
2014-11-18 14:28 ` Liviu Dudau
2014-11-19 1:19 ` Yijing Wang
2014-11-19 1:19 ` Yijing Wang
2014-11-19 1:19 ` Yijing Wang
2014-11-19 1:19 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:08 ` Arnd Bergmann
2014-11-17 10:08 ` Arnd Bergmann
2014-11-17 10:08 ` Arnd Bergmann
2014-11-17 10:08 ` Arnd Bergmann
2014-11-18 7:44 ` Yijing Wang
2014-11-18 7:44 ` Yijing Wang
2014-11-18 7:44 ` Yijing Wang
2014-11-18 7:44 ` Yijing Wang
2014-11-18 9:36 ` Arnd Bergmann
2014-11-18 9:36 ` Arnd Bergmann
2014-11-18 9:36 ` Arnd Bergmann
2014-11-18 9:36 ` Arnd Bergmann
2014-11-18 11:46 ` Yijing Wang
2014-11-18 11:46 ` Yijing Wang
2014-11-18 11:46 ` Yijing Wang
2014-11-18 11:46 ` Yijing Wang
2014-11-18 14:23 ` Liviu Dudau
2014-11-18 14:23 ` Liviu Dudau
2014-11-18 14:23 ` Liviu Dudau
2014-11-18 14:23 ` Liviu Dudau
2014-11-19 1:15 ` Yijing Wang
2014-11-19 1:15 ` Yijing Wang
2014-11-19 1:15 ` Yijing Wang
2014-11-19 1:15 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 08/16] PCI: Introduce pci_scan_host_bridge() and pci_host_info Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-18 15:42 ` Liviu Dudau
2014-11-18 15:42 ` Liviu Dudau
2014-11-18 15:42 ` Liviu Dudau
2014-11-18 15:42 ` Liviu Dudau
2014-11-19 2:09 ` Yijing Wang
2014-11-19 2:09 ` Yijing Wang
2014-11-19 2:09 ` Yijing Wang
2014-11-19 2:09 ` Yijing Wang
2014-11-19 16:41 ` Liviu Dudau
2014-11-19 16:41 ` Liviu Dudau
2014-11-19 16:41 ` Liviu Dudau
2014-11-19 16:41 ` Liviu Dudau
2014-11-20 2:54 ` Yijing Wang
2014-11-20 2:54 ` Yijing Wang
2014-11-20 2:54 ` Yijing Wang
2014-11-20 2:54 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 11/16] x86/PCI: Use pci_scan_host_bridge() instead of pci_create_root_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out " Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:56 ` Arnd Bergmann
2014-11-17 10:56 ` Arnd Bergmann
2014-11-17 10:56 ` Arnd Bergmann
2014-11-17 10:56 ` Arnd Bergmann
2014-11-18 8:32 ` Yijing Wang
2014-11-18 8:32 ` Yijing Wang
2014-11-18 8:32 ` Yijing Wang
2014-11-18 8:32 ` Yijing Wang
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 11:44 ` Yijing Wang
2014-11-18 11:44 ` Yijing Wang
2014-11-18 11:44 ` Yijing Wang
2014-11-18 11:44 ` Yijing Wang
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:41 ` Yijing Wang
2014-11-18 12:41 ` Yijing Wang
2014-11-18 12:41 ` Yijing Wang
2014-11-18 12:41 ` Yijing Wang
2014-11-18 14:48 ` Liviu Dudau
2014-11-18 14:48 ` Liviu Dudau
2014-11-18 14:48 ` Liviu Dudau
2014-11-18 14:48 ` Liviu Dudau
2014-11-19 2:24 ` Yijing Wang
2014-11-19 2:24 ` Yijing Wang
2014-11-19 2:24 ` Yijing Wang
2014-11-19 2:24 ` Yijing Wang
2014-11-19 16:29 ` Liviu Dudau
2014-11-19 16:29 ` Liviu Dudau
2014-11-19 16:29 ` Liviu Dudau
2014-11-20 2:00 ` Yijing Wang [this message]
2014-11-20 2:00 ` Yijing Wang
2014-11-20 2:00 ` Yijing Wang
2014-11-20 2:00 ` Yijing Wang
2014-11-18 15:30 ` Liviu Dudau
2014-11-18 15:30 ` Liviu Dudau
2014-11-18 15:30 ` Liviu Dudau
2014-11-18 15:30 ` Liviu Dudau
2014-11-19 1:42 ` Yijing Wang
2014-11-19 1:42 ` Yijing Wang
2014-11-19 1:42 ` Yijing Wang
2014-11-19 1:42 ` Yijing Wang
2014-11-19 16:37 ` Liviu Dudau
2014-11-19 16:37 ` Liviu Dudau
2014-11-19 16:37 ` Liviu Dudau
2014-11-19 16:37 ` Liviu Dudau
2014-11-20 2:47 ` Yijing Wang
2014-11-20 2:47 ` Yijing Wang
2014-11-20 2:47 ` Yijing Wang
2014-11-20 2:47 ` Yijing Wang
2014-11-20 9:47 ` Liviu Dudau
2014-11-20 9:47 ` Liviu Dudau
2014-11-20 9:47 ` Liviu Dudau
2014-11-20 9:47 ` Liviu Dudau
2014-11-21 2:53 ` Yijing Wang
2014-11-21 2:53 ` Yijing Wang
2014-11-21 2:53 ` Yijing Wang
2014-11-21 2:53 ` Yijing Wang
2014-11-21 9:53 ` Liviu Dudau
2014-11-21 9:53 ` Liviu Dudau
2014-11-21 9:53 ` Liviu Dudau
2014-11-21 9:53 ` Liviu Dudau
2014-11-17 14:13 ` [RFC PATCH 00/16] Refine PCI host bridge scan interfaces Arnd Bergmann
2014-11-17 14:13 ` Arnd Bergmann
2014-11-17 14:13 ` Arnd Bergmann
2014-11-17 14:13 ` Arnd Bergmann
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:45 ` Lorenzo Pieralisi
2014-11-18 11:45 ` Lorenzo Pieralisi
2014-11-18 11:45 ` Lorenzo Pieralisi
2014-11-18 12:14 ` Yijing Wang
2014-11-18 12:14 ` Yijing Wang
2014-11-18 12:14 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:27 ` Arnd Bergmann
2014-11-18 12:27 ` Arnd Bergmann
2014-11-18 12:27 ` Arnd Bergmann
2014-11-18 12:27 ` Arnd Bergmann
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 12:08 ` Liviu Dudau
2014-11-20 12:08 ` Liviu Dudau
2014-11-20 12:08 ` Liviu Dudau
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 16:39 ` Liviu Dudau
2014-11-20 16:39 ` Liviu Dudau
2014-11-20 16:39 ` Liviu Dudau
2014-11-21 2:58 ` Yijing Wang
2014-11-21 2:58 ` Yijing Wang
2014-11-21 2:58 ` Yijing Wang
2014-11-21 2:58 ` Yijing Wang
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=546D4B49.6020408@huawei.com \
--to=wangyijing@huawei.com \
--cc=Liviu.Dudau@arm.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=suravee.suthikulpanit@amd.com \
--cc=tglx@linutronix.de \
--cc=thierry.reding@gmail.com \
--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 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.