All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yijing Wang <wangyijing@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@lists.ozlabs.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	Liviu Dudau <liviu@dudau.co.uk>, Tony Luck <tony.luck@intel.com>,
	Russell King <linux@arm.linux.org.uk>,
	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, linux-ia64@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, Wuyun <wuyun.wu@huawei.com>,
	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: Tue, 18 Nov 2014 11:44:36 +0000	[thread overview]
Message-ID: <546B3124.7070206@huawei.com> (raw)
In-Reply-To: <1936415.emTbbPeHqx@wuerfel>

On 2014/11/18 17:30, Arnd Bergmann wrote:
> On Tuesday 18 November 2014 16:32:26 Yijing Wang wrote:
> 
>>>> +static struct resource busn_resource = {
>>>> +	.name	= "PCI busn",
>>>> +	.start	= 0,
>>>> +	.end	= 255,
>>>> +	.flags	= IORESOURCE_BUS,
>>>> +};
>>>
>>> I think it would be better to require callers to pass the bus resource
>>> down to the function.
>>
>> Hmm, I think most of caller will provide the bus resource, but some others
>> will not give any bus resource, extremely, no any resources :(. But we still
>> need properly configure their resources for compatibility.
> 
> I think that is what the conversion to pci_scan_bus_parented() is about:
> The idea is that we add the correct bus resource to callers of
> pci_scan_bus_parented or pci_scan_bus and then change them to call
> pci_scan_root_bus instead.

It looks good to me, but for simplification, or I will try to use a wrapper to
process the drivers don't pass the busnr resources, and make sure the generic
pci_create_host_bridge() always get the valid resources.

> 
>>>> +struct pci_host_bridge *pci_create_host_bridge(
>>>> +		struct device *parent, u32 db, 
>>>> +		struct pci_ops *ops, void *sysdata, 
>>>> +		struct list_head *resources)
>>>> +{
>>>
>>> Do we still need to pass the 'sysdata' in here? If we are guaranteed to
>>> have a device pointer, we should always be able to get the driver
>>> private data from dev_get_drvdata(host->dev->parent).
>>
>> We need, some platforms pass NULL pointer as host bridge parent.
> 
> But those don't have to use the new pci_create_host_bridge() function,
> right?

As I mentioned in another reply, I hope all pci host drivers could use
pci_create_host_bridge(), keep different PCI scan interfaces in PCI core
make things become complex.


> 
>>>> +	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.
> 
> It also depends on having a valid device pointer. The idea is that the memory
> is automatically freed if the probe() function returns with an error, or
> the device driver gets unloaded. For the classic PCI hosts that are not
> connected to a device, that wouldn't work of course.
> 
> 	Arnd
> 
> .
> 


-- 
Thanks!
Yijing


WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: <linuxppc-dev@lists.ozlabs.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Liviu Dudau <liviu@dudau.co.uk>, Tony Luck <tony.luck@intel.com>,
	"Russell King" <linux@arm.linux.org.uk>,
	<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>, <linux-ia64@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, Wuyun <wuyun.wu@huawei.com>,
	<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: Tue, 18 Nov 2014 19:44:36 +0800	[thread overview]
Message-ID: <546B3124.7070206@huawei.com> (raw)
In-Reply-To: <1936415.emTbbPeHqx@wuerfel>

On 2014/11/18 17:30, Arnd Bergmann wrote:
> On Tuesday 18 November 2014 16:32:26 Yijing Wang wrote:
> 
>>>> +static struct resource busn_resource = {
>>>> +	.name	= "PCI busn",
>>>> +	.start	= 0,
>>>> +	.end	= 255,
>>>> +	.flags	= IORESOURCE_BUS,
>>>> +};
>>>
>>> I think it would be better to require callers to pass the bus resource
>>> down to the function.
>>
>> Hmm, I think most of caller will provide the bus resource, but some others
>> will not give any bus resource, extremely, no any resources :(. But we still
>> need properly configure their resources for compatibility.
> 
> I think that is what the conversion to pci_scan_bus_parented() is about:
> The idea is that we add the correct bus resource to callers of
> pci_scan_bus_parented or pci_scan_bus and then change them to call
> pci_scan_root_bus instead.

It looks good to me, but for simplification, or I will try to use a wrapper to
process the drivers don't pass the busnr resources, and make sure the generic
pci_create_host_bridge() always get the valid resources.

> 
>>>> +struct pci_host_bridge *pci_create_host_bridge(
>>>> +		struct device *parent, u32 db, 
>>>> +		struct pci_ops *ops, void *sysdata, 
>>>> +		struct list_head *resources)
>>>> +{
>>>
>>> Do we still need to pass the 'sysdata' in here? If we are guaranteed to
>>> have a device pointer, we should always be able to get the driver
>>> private data from dev_get_drvdata(host->dev->parent).
>>
>> We need, some platforms pass NULL pointer as host bridge parent.
> 
> But those don't have to use the new pci_create_host_bridge() function,
> right?

As I mentioned in another reply, I hope all pci host drivers could use
pci_create_host_bridge(), keep different PCI scan interfaces in PCI core
make things become complex.


> 
>>>> +	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.
> 
> It also depends on having a valid device pointer. The idea is that the memory
> is automatically freed if the probe() function returns with an error, or
> the device driver gets unloaded. For the classic PCI hosts that are not
> connected to a device, that wouldn't work of course.
> 
> 	Arnd
> 
> .
> 


-- 
Thanks!
Yijing


WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Liviu Dudau <liviu@dudau.co.uk>, Tony Luck <tony.luck@intel.com>,
	Russell King <linux@arm.linux.org.uk>,
	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 07/16] PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
Date: Tue, 18 Nov 2014 19:44:36 +0800	[thread overview]
Message-ID: <546B3124.7070206@huawei.com> (raw)
In-Reply-To: <1936415.emTbbPeHqx@wuerfel>

On 2014/11/18 17:30, Arnd Bergmann wrote:
> On Tuesday 18 November 2014 16:32:26 Yijing Wang wrote:
> 
>>>> +static struct resource busn_resource = {
>>>> +	.name	= "PCI busn",
>>>> +	.start	= 0,
>>>> +	.end	= 255,
>>>> +	.flags	= IORESOURCE_BUS,
>>>> +};
>>>
>>> I think it would be better to require callers to pass the bus resource
>>> down to the function.
>>
>> Hmm, I think most of caller will provide the bus resource, but some others
>> will not give any bus resource, extremely, no any resources :(. But we still
>> need properly configure their resources for compatibility.
> 
> I think that is what the conversion to pci_scan_bus_parented() is about:
> The idea is that we add the correct bus resource to callers of
> pci_scan_bus_parented or pci_scan_bus and then change them to call
> pci_scan_root_bus instead.

It looks good to me, but for simplification, or I will try to use a wrapper to
process the drivers don't pass the busnr resources, and make sure the generic
pci_create_host_bridge() always get the valid resources.

> 
>>>> +struct pci_host_bridge *pci_create_host_bridge(
>>>> +		struct device *parent, u32 db, 
>>>> +		struct pci_ops *ops, void *sysdata, 
>>>> +		struct list_head *resources)
>>>> +{
>>>
>>> Do we still need to pass the 'sysdata' in here? If we are guaranteed to
>>> have a device pointer, we should always be able to get the driver
>>> private data from dev_get_drvdata(host->dev->parent).
>>
>> We need, some platforms pass NULL pointer as host bridge parent.
> 
> But those don't have to use the new pci_create_host_bridge() function,
> right?

As I mentioned in another reply, I hope all pci host drivers could use
pci_create_host_bridge(), keep different PCI scan interfaces in PCI core
make things become complex.


> 
>>>> +	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.
> 
> It also depends on having a valid device pointer. The idea is that the memory
> is automatically freed if the probe() function returns with an error, or
> the device driver gets unloaded. For the classic PCI hosts that are not
> connected to a device, that wouldn't work of course.
> 
> 	Arnd
> 
> .
> 


-- 
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: Tue, 18 Nov 2014 19:44:36 +0800	[thread overview]
Message-ID: <546B3124.7070206@huawei.com> (raw)
In-Reply-To: <1936415.emTbbPeHqx@wuerfel>

On 2014/11/18 17:30, Arnd Bergmann wrote:
> On Tuesday 18 November 2014 16:32:26 Yijing Wang wrote:
> 
>>>> +static struct resource busn_resource = {
>>>> +	.name	= "PCI busn",
>>>> +	.start	= 0,
>>>> +	.end	= 255,
>>>> +	.flags	= IORESOURCE_BUS,
>>>> +};
>>>
>>> I think it would be better to require callers to pass the bus resource
>>> down to the function.
>>
>> Hmm, I think most of caller will provide the bus resource, but some others
>> will not give any bus resource, extremely, no any resources :(. But we still
>> need properly configure their resources for compatibility.
> 
> I think that is what the conversion to pci_scan_bus_parented() is about:
> The idea is that we add the correct bus resource to callers of
> pci_scan_bus_parented or pci_scan_bus and then change them to call
> pci_scan_root_bus instead.

It looks good to me, but for simplification, or I will try to use a wrapper to
process the drivers don't pass the busnr resources, and make sure the generic
pci_create_host_bridge() always get the valid resources.

> 
>>>> +struct pci_host_bridge *pci_create_host_bridge(
>>>> +		struct device *parent, u32 db, 
>>>> +		struct pci_ops *ops, void *sysdata, 
>>>> +		struct list_head *resources)
>>>> +{
>>>
>>> Do we still need to pass the 'sysdata' in here? If we are guaranteed to
>>> have a device pointer, we should always be able to get the driver
>>> private data from dev_get_drvdata(host->dev->parent).
>>
>> We need, some platforms pass NULL pointer as host bridge parent.
> 
> But those don't have to use the new pci_create_host_bridge() function,
> right?

As I mentioned in another reply, I hope all pci host drivers could use
pci_create_host_bridge(), keep different PCI scan interfaces in PCI core
make things become complex.


> 
>>>> +	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.
> 
> It also depends on having a valid device pointer. The idea is that the memory
> is automatically freed if the probe() function returns with an error, or
> the device driver gets unloaded. For the classic PCI hosts that are not
> connected to a device, that wouldn't work of course.
> 
> 	Arnd
> 
> .
> 


-- 
Thanks!
Yijing

  reply	other threads:[~2014-11-18 11:44 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 07/16] PCI: Separate pci_host_bridge creation out 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 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 [this message]
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
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  9:45 ` [RFC PATCH 11/16] x86/PCI: Use pci_scan_host_bridge() instead " 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 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=546B3124.7070206@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=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.