All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yijing Wang <wangyijing@huawei.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
	<linux-pci@vger.kernel.org>, Yinghai Lu <yinghai@kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	Russell King <linux@arm.linux.org.uk>, <dja@axtens.net>,
	<x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Tony Luck <tony.luck@intel.com>, <linux-ia64@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Guan Xuetao" <gxt@mprc.pku.edu.cn>,
	<linux-alpha@vger.kernel.org>, <linux-m68k@vger.kernel.org>,
	Liviu Dudau <liviu@dudau.co.uk>, "Arnd Bergmann" <arnd@arndb.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"Yijing Wang" <wangyijing0307@gmail.com>
Subject: Re: [PATCH v9 08/30] PCI: Update pci_host_bridge bus resource
Date: Wed, 8 Apr 2015 17:22:05 +0800	[thread overview]
Message-ID: <5524F33D.7090800@huawei.com> (raw)
In-Reply-To: <20150407224243.GL10892@google.com>

On 2015/4/8 6:42, Bjorn Helgaas wrote:
> On Fri, Apr 03, 2015 at 05:25:42PM +0800, Yijing Wang wrote:
>> From: Yijing Wang <wangyijing0307@gmail.com>
>>
>> Sometimes, the bus resource start number is not equal to
>> root bus number. For example, in pci_scan_bus(), we always
>> add the default bus resource which start bus number is 0,
>> but the root bus number callers given may != 0, so
>> we need to update pci_host_bridge bus resource, because we
>> would check whether host bridge bus resoruce is confict
>> in later patch.
> 
> It's true that pci_scan_bus() always inserts [bus 00-ff].  But I think
> that's completely bogus.  The caller of pci_scan_bus() supplies a root bus
> number X.  Any bus numbers below X are useless as far as this host bridge
> is concerned, and it's pointless to include them in the range inserted by
> pci_scan_bus().

Agree, I think it's better to use the [bus start - FF] instead of [00-FF].

> 
> I think we'd be better off if we forced every pci_scan_bus() caller to
> supply a real non-overlapping bus number range.  We probably can't do that
> easily because the arch knows the beginning bus number, but some don't know
> how to figure out the ending bus number.

It seems to have some problems in pci_scan_bus() if we have more than one pci host bridge
in a domain. Because we add the default busn_res[00-FF] to resource list in pci_scan_bus(),
and pass the resource list to pci_create_root_bus().  The pci root bus would
consume the bus range from the start to the 0xFF, and request it from the per-domain resource[00-FF].
So if we have another pci host bridge in this domain, and pass another start bus number, it would
fail when the root bus try to request bus resource from per-domain resource. Now only several archs
call pci_scan_bus(), I guess they didn't run the code in above case, so we didn't find
the bus report.

> 
> Do we have a per-domain structure that tracks the bus numbers in use in the
> domain?  It seems like if we had one, we could use that to approximate the
> end.  For example, if the arch scans three root buses, at bus 00, bus 40,
> and bus 80, we could start with the first one at [bus 00-ff], and when we
> scan the one at bus 40, we could either report a conflict (if the bus 00
> tree included a bus 40) or reduce the first range to [bus 00-3f].

Per-domain resource pci_domain_busn_res is what we are looking for.
For simplicity, we could report a conflict and fail when we find a conflict bus
resource in system.


>>  	resource_list_for_each_entry(window, resources)
>> -		if (window->res->flags & IORESOURCE_BUS)
>> +		if (window->res->flags & IORESOURCE_BUS) {
>> +			if (bus > window->res->start)
>> +				window->res->start = bus;
> 
> I see what you're trying to do here, but I think this is the wrong place to
> do it.  I'd rather figure out a way to insert something other than
> busn_resource in pci_scan_bus().  That probably means we need to
> dynamically allocate a new busn_res struct.

Allocate a new busn_res maybe unnecessary, the bus resource we added to resource list
and passed to pci_create_root_bus() will never be used again after we call
pci_bus_insert_busn_res(), we may could consider to use local busn_res in pci_scan_bus().

Thanks!
Yijing.

> 
>>  			return;
>> +		}
>>  
>>  	pr_info(
>>  	 "No busn resource found for pci%04x:%02x, will use [bus %02x-ff]\n",
>> -- 
>> 1.7.1
>>
>> --
>> 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


WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
	linux-pci@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>,
	linux-kernel@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Russell King <linux@arm.linux.org.uk>,
	dja@axtens.net, x86@kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Guan Xuetao <gxt@mprc.pku.edu.cn>,
	linux-alpha@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	Liviu Dudau <liviu@dudau.co.uk>, Arnd Bergmann <arnd@arndb.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yijing Wang <wangyijing0307@gmail.com>
Subject: Re: [PATCH v9 08/30] PCI: Update pci_host_bridge bus resource
Date: Wed, 8 Apr 2015 17:22:05 +0800	[thread overview]
Message-ID: <5524F33D.7090800@huawei.com> (raw)
In-Reply-To: <20150407224243.GL10892@google.com>

On 2015/4/8 6:42, Bjorn Helgaas wrote:
> On Fri, Apr 03, 2015 at 05:25:42PM +0800, Yijing Wang wrote:
>> From: Yijing Wang <wangyijing0307@gmail.com>
>>
>> Sometimes, the bus resource start number is not equal to
>> root bus number. For example, in pci_scan_bus(), we always
>> add the default bus resource which start bus number is 0,
>> but the root bus number callers given may != 0, so
>> we need to update pci_host_bridge bus resource, because we
>> would check whether host bridge bus resoruce is confict
>> in later patch.
> 
> It's true that pci_scan_bus() always inserts [bus 00-ff].  But I think
> that's completely bogus.  The caller of pci_scan_bus() supplies a root bus
> number X.  Any bus numbers below X are useless as far as this host bridge
> is concerned, and it's pointless to include them in the range inserted by
> pci_scan_bus().

Agree, I think it's better to use the [bus start - FF] instead of [00-FF].

> 
> I think we'd be better off if we forced every pci_scan_bus() caller to
> supply a real non-overlapping bus number range.  We probably can't do that
> easily because the arch knows the beginning bus number, but some don't know
> how to figure out the ending bus number.

It seems to have some problems in pci_scan_bus() if we have more than one pci host bridge
in a domain. Because we add the default busn_res[00-FF] to resource list in pci_scan_bus(),
and pass the resource list to pci_create_root_bus().  The pci root bus would
consume the bus range from the start to the 0xFF, and request it from the per-domain resource[00-FF].
So if we have another pci host bridge in this domain, and pass another start bus number, it would
fail when the root bus try to request bus resource from per-domain resource. Now only several archs
call pci_scan_bus(), I guess they didn't run the code in above case, so we didn't find
the bus report.

> 
> Do we have a per-domain structure that tracks the bus numbers in use in the
> domain?  It seems like if we had one, we could use that to approximate the
> end.  For example, if the arch scans three root buses, at bus 00, bus 40,
> and bus 80, we could start with the first one at [bus 00-ff], and when we
> scan the one at bus 40, we could either report a conflict (if the bus 00
> tree included a bus 40) or reduce the first range to [bus 00-3f].

Per-domain resource pci_domain_busn_res is what we are looking for.
For simplicity, we could report a conflict and fail when we find a conflict bus
resource in system.


>>  	resource_list_for_each_entry(window, resources)
>> -		if (window->res->flags & IORESOURCE_BUS)
>> +		if (window->res->flags & IORESOURCE_BUS) {
>> +			if (bus > window->res->start)
>> +				window->res->start = bus;
> 
> I see what you're trying to do here, but I think this is the wrong place to
> do it.  I'd rather figure out a way to insert something other than
> busn_resource in pci_scan_bus().  That probably means we need to
> dynamically allocate a new busn_res struct.

Allocate a new busn_res maybe unnecessary, the bus resource we added to resource list
and passed to pci_create_root_bus() will never be used again after we call
pci_bus_insert_busn_res(), we may could consider to use local busn_res in pci_scan_bus().

Thanks!
Yijing.

> 
>>  			return;
>> +		}
>>  
>>  	pr_info(
>>  	 "No busn resource found for pci%04x:%02x, will use [bus %02x-ff]\n",
>> -- 
>> 1.7.1
>>
>> --
>> 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

WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
	<linux-pci@vger.kernel.org>, Yinghai Lu <yinghai@kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	<linux-arm-kernel@lists.infradead.org>,
	Russell King <linux@arm.linux.org.uk>, <dja@axtens.net>,
	<x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Tony Luck <tony.luck@intel.com>, <linux-ia64@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Guan Xuetao" <gxt@mprc.pku.edu.cn>,
	<linux-alpha@vger.kernel.org>, <linux-m68k@lists.linux-m68k.org>,
	Liviu Dudau <liviu@dudau.co.uk>, "Arnd Bergmann" <arnd@arndb.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"Yijing Wang" <wangyijing0307@gmail.com>
Subject: Re: [PATCH v9 08/30] PCI: Update pci_host_bridge bus resource
Date: Wed, 8 Apr 2015 17:22:05 +0800	[thread overview]
Message-ID: <5524F33D.7090800@huawei.com> (raw)
In-Reply-To: <20150407224243.GL10892@google.com>

On 2015/4/8 6:42, Bjorn Helgaas wrote:
> On Fri, Apr 03, 2015 at 05:25:42PM +0800, Yijing Wang wrote:
>> From: Yijing Wang <wangyijing0307@gmail.com>
>>
>> Sometimes, the bus resource start number is not equal to
>> root bus number. For example, in pci_scan_bus(), we always
>> add the default bus resource which start bus number is 0,
>> but the root bus number callers given may != 0, so
>> we need to update pci_host_bridge bus resource, because we
>> would check whether host bridge bus resoruce is confict
>> in later patch.
> 
> It's true that pci_scan_bus() always inserts [bus 00-ff].  But I think
> that's completely bogus.  The caller of pci_scan_bus() supplies a root bus
> number X.  Any bus numbers below X are useless as far as this host bridge
> is concerned, and it's pointless to include them in the range inserted by
> pci_scan_bus().

Agree, I think it's better to use the [bus start - FF] instead of [00-FF].

> 
> I think we'd be better off if we forced every pci_scan_bus() caller to
> supply a real non-overlapping bus number range.  We probably can't do that
> easily because the arch knows the beginning bus number, but some don't know
> how to figure out the ending bus number.

It seems to have some problems in pci_scan_bus() if we have more than one pci host bridge
in a domain. Because we add the default busn_res[00-FF] to resource list in pci_scan_bus(),
and pass the resource list to pci_create_root_bus().  The pci root bus would
consume the bus range from the start to the 0xFF, and request it from the per-domain resource[00-FF].
So if we have another pci host bridge in this domain, and pass another start bus number, it would
fail when the root bus try to request bus resource from per-domain resource. Now only several archs
call pci_scan_bus(), I guess they didn't run the code in above case, so we didn't find
the bus report.

> 
> Do we have a per-domain structure that tracks the bus numbers in use in the
> domain?  It seems like if we had one, we could use that to approximate the
> end.  For example, if the arch scans three root buses, at bus 00, bus 40,
> and bus 80, we could start with the first one at [bus 00-ff], and when we
> scan the one at bus 40, we could either report a conflict (if the bus 00
> tree included a bus 40) or reduce the first range to [bus 00-3f].

Per-domain resource pci_domain_busn_res is what we are looking for.
For simplicity, we could report a conflict and fail when we find a conflict bus
resource in system.


>>  	resource_list_for_each_entry(window, resources)
>> -		if (window->res->flags & IORESOURCE_BUS)
>> +		if (window->res->flags & IORESOURCE_BUS) {
>> +			if (bus > window->res->start)
>> +				window->res->start = bus;
> 
> I see what you're trying to do here, but I think this is the wrong place to
> do it.  I'd rather figure out a way to insert something other than
> busn_resource in pci_scan_bus().  That probably means we need to
> dynamically allocate a new busn_res struct.

Allocate a new busn_res maybe unnecessary, the bus resource we added to resource list
and passed to pci_create_root_bus() will never be used again after we call
pci_bus_insert_busn_res(), we may could consider to use local busn_res in pci_scan_bus().

Thanks!
Yijing.

> 
>>  			return;
>> +		}
>>  
>>  	pr_info(
>>  	 "No busn resource found for pci%04x:%02x, will use [bus %02x-ff]\n",
>> -- 
>> 1.7.1
>>
>> --
>> 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


WARNING: multiple messages have this Message-ID (diff)
From: wangyijing@huawei.com (Yijing Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 08/30] PCI: Update pci_host_bridge bus resource
Date: Wed, 8 Apr 2015 17:22:05 +0800	[thread overview]
Message-ID: <5524F33D.7090800@huawei.com> (raw)
In-Reply-To: <20150407224243.GL10892@google.com>

On 2015/4/8 6:42, Bjorn Helgaas wrote:
> On Fri, Apr 03, 2015 at 05:25:42PM +0800, Yijing Wang wrote:
>> From: Yijing Wang <wangyijing0307@gmail.com>
>>
>> Sometimes, the bus resource start number is not equal to
>> root bus number. For example, in pci_scan_bus(), we always
>> add the default bus resource which start bus number is 0,
>> but the root bus number callers given may != 0, so
>> we need to update pci_host_bridge bus resource, because we
>> would check whether host bridge bus resoruce is confict
>> in later patch.
> 
> It's true that pci_scan_bus() always inserts [bus 00-ff].  But I think
> that's completely bogus.  The caller of pci_scan_bus() supplies a root bus
> number X.  Any bus numbers below X are useless as far as this host bridge
> is concerned, and it's pointless to include them in the range inserted by
> pci_scan_bus().

Agree, I think it's better to use the [bus start - FF] instead of [00-FF].

> 
> I think we'd be better off if we forced every pci_scan_bus() caller to
> supply a real non-overlapping bus number range.  We probably can't do that
> easily because the arch knows the beginning bus number, but some don't know
> how to figure out the ending bus number.

It seems to have some problems in pci_scan_bus() if we have more than one pci host bridge
in a domain. Because we add the default busn_res[00-FF] to resource list in pci_scan_bus(),
and pass the resource list to pci_create_root_bus().  The pci root bus would
consume the bus range from the start to the 0xFF, and request it from the per-domain resource[00-FF].
So if we have another pci host bridge in this domain, and pass another start bus number, it would
fail when the root bus try to request bus resource from per-domain resource. Now only several archs
call pci_scan_bus(), I guess they didn't run the code in above case, so we didn't find
the bus report.

> 
> Do we have a per-domain structure that tracks the bus numbers in use in the
> domain?  It seems like if we had one, we could use that to approximate the
> end.  For example, if the arch scans three root buses, at bus 00, bus 40,
> and bus 80, we could start with the first one at [bus 00-ff], and when we
> scan the one at bus 40, we could either report a conflict (if the bus 00
> tree included a bus 40) or reduce the first range to [bus 00-3f].

Per-domain resource pci_domain_busn_res is what we are looking for.
For simplicity, we could report a conflict and fail when we find a conflict bus
resource in system.


>>  	resource_list_for_each_entry(window, resources)
>> -		if (window->res->flags & IORESOURCE_BUS)
>> +		if (window->res->flags & IORESOURCE_BUS) {
>> +			if (bus > window->res->start)
>> +				window->res->start = bus;
> 
> I see what you're trying to do here, but I think this is the wrong place to
> do it.  I'd rather figure out a way to insert something other than
> busn_resource in pci_scan_bus().  That probably means we need to
> dynamically allocate a new busn_res struct.

Allocate a new busn_res maybe unnecessary, the bus resource we added to resource list
and passed to pci_create_root_bus() will never be used again after we call
pci_bus_insert_busn_res(), we may could consider to use local busn_res in pci_scan_bus().

Thanks!
Yijing.

> 
>>  			return;
>> +		}
>>  
>>  	pr_info(
>>  	 "No busn resource found for pci%04x:%02x, will use [bus %02x-ff]\n",
>> -- 
>> 1.7.1
>>
>> --
>> 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

WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>,
	linux-pci@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>,
	linux-kernel@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Russell King <linux@arm.linux.org.uk>,
	dja@axtens.net, x86@kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Tony Luck <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Guan Xuetao <gxt@mprc.pku.edu.cn>,
	linux-alpha@vger.kernel.org, linux-m68k@vger.kernel.org,
	Liviu Dudau <liviu@dudau.co.uk>, Arnd Bergmann <arnd@arndb.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yijing Wang <wangyijing0307@gmail.com>
Subject: Re: [PATCH v9 08/30] PCI: Update pci_host_bridge bus resource
Date: Wed, 08 Apr 2015 09:22:05 +0000	[thread overview]
Message-ID: <5524F33D.7090800@huawei.com> (raw)
In-Reply-To: <20150407224243.GL10892@google.com>

On 2015/4/8 6:42, Bjorn Helgaas wrote:
> On Fri, Apr 03, 2015 at 05:25:42PM +0800, Yijing Wang wrote:
>> From: Yijing Wang <wangyijing0307@gmail.com>
>>
>> Sometimes, the bus resource start number is not equal to
>> root bus number. For example, in pci_scan_bus(), we always
>> add the default bus resource which start bus number is 0,
>> but the root bus number callers given may != 0, so
>> we need to update pci_host_bridge bus resource, because we
>> would check whether host bridge bus resoruce is confict
>> in later patch.
> 
> It's true that pci_scan_bus() always inserts [bus 00-ff].  But I think
> that's completely bogus.  The caller of pci_scan_bus() supplies a root bus
> number X.  Any bus numbers below X are useless as far as this host bridge
> is concerned, and it's pointless to include them in the range inserted by
> pci_scan_bus().

Agree, I think it's better to use the [bus start - FF] instead of [00-FF].

> 
> I think we'd be better off if we forced every pci_scan_bus() caller to
> supply a real non-overlapping bus number range.  We probably can't do that
> easily because the arch knows the beginning bus number, but some don't know
> how to figure out the ending bus number.

It seems to have some problems in pci_scan_bus() if we have more than one pci host bridge
in a domain. Because we add the default busn_res[00-FF] to resource list in pci_scan_bus(),
and pass the resource list to pci_create_root_bus().  The pci root bus would
consume the bus range from the start to the 0xFF, and request it from the per-domain resource[00-FF].
So if we have another pci host bridge in this domain, and pass another start bus number, it would
fail when the root bus try to request bus resource from per-domain resource. Now only several archs
call pci_scan_bus(), I guess they didn't run the code in above case, so we didn't find
the bus report.

> 
> Do we have a per-domain structure that tracks the bus numbers in use in the
> domain?  It seems like if we had one, we could use that to approximate the
> end.  For example, if the arch scans three root buses, at bus 00, bus 40,
> and bus 80, we could start with the first one at [bus 00-ff], and when we
> scan the one at bus 40, we could either report a conflict (if the bus 00
> tree included a bus 40) or reduce the first range to [bus 00-3f].

Per-domain resource pci_domain_busn_res is what we are looking for.
For simplicity, we could report a conflict and fail when we find a conflict bus
resource in system.


>>  	resource_list_for_each_entry(window, resources)
>> -		if (window->res->flags & IORESOURCE_BUS)
>> +		if (window->res->flags & IORESOURCE_BUS) {
>> +			if (bus > window->res->start)
>> +				window->res->start = bus;
> 
> I see what you're trying to do here, but I think this is the wrong place to
> do it.  I'd rather figure out a way to insert something other than
> busn_resource in pci_scan_bus().  That probably means we need to
> dynamically allocate a new busn_res struct.

Allocate a new busn_res maybe unnecessary, the bus resource we added to resource list
and passed to pci_create_root_bus() will never be used again after we call
pci_bus_insert_busn_res(), we may could consider to use local busn_res in pci_scan_bus().

Thanks!
Yijing.

> 
>>  			return;
>> +		}
>>  
>>  	pr_info(
>>  	 "No busn resource found for pci%04x:%02x, will use [bus %02x-ff]\n",
>> -- 
>> 1.7.1
>>
>> --
>> 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


  reply	other threads:[~2015-04-08  9:22 UTC|newest]

Thread overview: 266+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-03  9:25 [PATCH v9 00/30] Refine PCI scan interfaces and make generic pci host bridge Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH] PCI: Save sysdata in pci_host_bridge drvdata Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:32   ` Yijing Wang
2015-04-03  9:32   ` Yijing Wang
2015-04-03  9:32     ` Yijing Wang
2015-04-03  9:32     ` Yijing Wang
2015-04-03  9:32     ` Yijing Wang
2015-04-03  9:32     ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 01/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented() Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 02/30] PCI: Remove deprecated pci_scan_bus_parented() Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 03/30] PCI: Save domain in pci_host_bridge Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-08  8:09   ` Gregory CLEMENT
2015-04-08  8:09     ` Gregory CLEMENT
2015-04-08  8:09     ` Gregory CLEMENT
2015-04-08  8:09     ` Gregory CLEMENT
2015-04-08  8:32     ` Yijing Wang
2015-04-08  8:32     ` Yijing Wang
2015-04-08  8:32       ` Yijing Wang
2015-04-08  8:32       ` Yijing Wang
2015-04-08  8:32       ` Yijing Wang
2015-04-08  8:32       ` Yijing Wang
2015-04-08  8:09   ` Gregory CLEMENT
2015-04-03  9:25 ` [PATCH v9 04/30] PCI: Move pci_bus_assign_domain_nr() declaration into drivers/pci/pci.h Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 05/30] PCI: Introduce pci_host_assign_domain_nr() to assign domain Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 06/30] PCI: Separate pci_host_bridge creation out of pci_create_root_bus() Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-07 21:38   ` Bjorn Helgaas
2015-04-07 21:38     ` Bjorn Helgaas
2015-04-07 21:38     ` Bjorn Helgaas
2015-04-07 21:38     ` Bjorn Helgaas
2015-04-08  1:18     ` Yijing Wang
2015-04-08  1:18       ` Yijing Wang
2015-04-08  1:18       ` Yijing Wang
2015-04-08  1:18       ` Yijing Wang
2015-04-08  1:18       ` Yijing Wang
2015-04-08  1:18     ` Yijing Wang
2015-04-07 21:38   ` Bjorn Helgaas
2015-04-03  9:25 ` [PATCH v9 07/30] PCI: Add default bus resource in pci_host_bridge Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-07 22:25   ` Bjorn Helgaas
2015-04-07 22:25   ` Bjorn Helgaas
2015-04-07 22:25     ` Bjorn Helgaas
2015-04-07 22:25     ` Bjorn Helgaas
2015-04-07 22:25     ` Bjorn Helgaas
2015-04-08  8:14     ` Yijing Wang
2015-04-08  8:14     ` Yijing Wang
2015-04-08  8:14       ` Yijing Wang
2015-04-08  8:14       ` Yijing Wang
2015-04-08  8:14       ` Yijing Wang
2015-04-08  8:14       ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 08/30] PCI: Update pci_host_bridge bus resource Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-07 22:42   ` Bjorn Helgaas
2015-04-07 22:42     ` Bjorn Helgaas
2015-04-07 22:42     ` Bjorn Helgaas
2015-04-07 22:42     ` Bjorn Helgaas
2015-04-08  9:22     ` Yijing Wang [this message]
2015-04-08  9:22       ` Yijing Wang
2015-04-08  9:22       ` Yijing Wang
2015-04-08  9:22       ` Yijing Wang
2015-04-08  9:22       ` Yijing Wang
2015-04-07 22:42   ` Bjorn Helgaas
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 09/30] PCI: Introduce pci_host_first_busnr() function Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 10/30] PCI: Introduce pci_host_bridge_list to manage host bridges Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 11/30] PCI: Save sysdata in pci_host_bridge drvdata Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 12/30] powerpc/PCI: Rename pcibios_root_bridge_prepare() to pcibios_set_root_bus_speed() Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 13/30] PCI: Move pcibios_root_bridge_prepare() to pci_create_host_bridge() Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 14/30] PCI: Introduce pci_host_bridge_ops to support host specific operations Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-07  7:04   ` Daniel Axtens
2015-04-07  7:04   ` Daniel Axtens
2015-04-07  7:04     ` Daniel Axtens
2015-04-07  7:04     ` Daniel Axtens
2015-04-07  7:04     ` Daniel Axtens
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 15/30] PCI: Introduce new scan function pci_scan_host_bridge() Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 16/30] PCI: Introduce pci_bus_child_max_busnr() Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 17/30] x86/PCI: Refine pci_acpi_scan_root() with generic pci_host_bridge Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 18/30] ia64/PCI: " Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 19/30] powerpc/pci: Use pci_scan_host_bridge() for simplicity Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-06 23:35   ` Daniel Axtens
2015-04-06 23:35     ` Daniel Axtens
2015-04-06 23:35     ` Daniel Axtens
2015-04-06 23:35     ` Daniel Axtens
2015-04-06 23:35     ` Daniel Axtens
2015-04-07  2:52     ` Yijing Wang
2015-04-07  2:52       ` Yijing Wang
2015-04-07  2:52       ` Yijing Wang
2015-04-07  2:52       ` Yijing Wang
2015-04-07  2:52       ` Yijing Wang
2015-04-07  2:52       ` Yijing Wang
2015-04-07  2:52     ` Yijing Wang
2015-04-06 23:35   ` Daniel Axtens
2015-04-03  9:25 ` [PATCH v9 20/30] PCI: Remove pcibios_root_bridge_prepare() and pcibos_set_root_bus_speed() Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 21/30] sparc/PCI: Use pci_scan_host_bridge() for simplicity Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 22/30] parisc/PCI: Use pci_scan_root_bus() " Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 23/30] PCI/mvebu: Use pci_common_init_dev() to simplify code Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-08  8:08   ` Gregory CLEMENT
2015-04-08  8:08   ` Gregory CLEMENT
2015-04-08  8:08     ` Gregory CLEMENT
2015-04-08  8:08     ` Gregory CLEMENT
2015-04-08  8:08     ` Gregory CLEMENT
2015-04-08  8:30     ` Yijing Wang
2015-04-08  8:30     ` Yijing Wang
2015-04-08  8:30       ` Yijing Wang
2015-04-08  8:30       ` Yijing Wang
2015-04-08  8:30       ` Yijing Wang
2015-04-08  8:30       ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 24/30] PCI/tegra: Remove redundant tegra_pcie_scan_bus() Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25 ` [PATCH v9 25/30] PCI/designware: Use pci_scan_root_bus() for simplicity Yijing Wang
2015-04-03  9:25 ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:25   ` Yijing Wang
2015-04-03  9:26 ` [PATCH v9 26/30] PCI/xgene: Use pci_scan_root_bus() instead of pci_create_root_bus() Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26 ` Yijing Wang
2015-04-03  9:26 ` [PATCH v9 27/30] PCI: Rename __pci_create_root_bus() to pci_create_root_bus() Yijing Wang
2015-04-03  9:26 ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26 ` [PATCH v9 28/30] PCI: Remove platform specific pci_domain_nr() Yijing Wang
2015-04-03  9:26 ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26 ` [PATCH v9 29/30] PCI: Remove pci_bus_assign_domain_nr() Yijing Wang
2015-04-03  9:26 ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26 ` [PATCH v9 30/30] PCI: Clean up CONFIG_PCI_DOMAINS_GENERIC Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` Yijing Wang
2015-04-03  9:26   ` 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=5524F33D.7090800@huawei.com \
    --to=wangyijing@huawei.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=dja@axtens.net \
    --cc=geert@linux-m68k.org \
    --cc=gxt@mprc.pku.edu.cn \
    --cc=jiang.liu@linux.intel.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=liviu@dudau.co.uk \
    --cc=marc.zyngier@arm.com \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=wangyijing0307@gmail.com \
    --cc=x86@kernel.org \
    --cc=yinghai@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.