On Wed, Apr 25, 2012 at 09:28:19AM -0700, Yinghai Lu wrote:
>On Wed, Apr 25, 2012 at 2:47 AM, Wei Yang <[email protected]> wrote:
>>> busn_alloc patchset should address your concern.
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>>> for-pci-busn-alloc
>>>
>> Yinghai
>>
>> You mean this patch 44b2347b fix the problem?
>>
>> In the comment, "do pass0 for all good bridge".
>> Then there are totally two pass for a whole pci domain?
>
>also other commits about strict checking to see if it is good.
>
>>
>> I tried "git grep busn_alloc", but not find anything.
>
>the commit in the patchset.
>
> PCI: Add busn_res into struct pci_bus.
> PCI: Add busn_res operation functions
> PCI: Release busn_res when removing bus
> PCI: Insert busn_res in pci_create_root_bus()
> PCI: Checking busn_res in pci_scan_root_bus()
> PCI: Add default busn_resource
> PCI: Add default busn_res for pci_scan_bus()
> x86, PCI: Add busn_res into resources list for acpi path
> x86, PCI: Put busn resource in pci_root_info for not using _CRS path
> PCI, ia64: Register busn_res for root buses
> PCI, sparc: Register busn_res for root buses
> PCI, powerpc: Register busn_res for root buses
> PCI, parisc: Register busn_res for root buses
> resources: Add probe_resource()
> resources: Replace registered resource in tree.
> PCI: Add pci_bus_extend/shrink_top()
> PCI: Probe safe range that we can use for unassigned bridge.
> PCI: Add pci_bus_replace_busn_res()
> PCI: Allocate bus range instead of use max blindly
> PCI: Strict checking of valid range for bridge
> PCI: Kill pci_fixup_parent_subordinate_busnr()
> PCI: Seperate child bus scanning to two passes overall
> pcmcia: Remove workaround for fixing pci parent bus subordinate
> PCI: Double checking setting for bus register and bus struct.
> PCI, pciehp: Remove not needed bus number range checking
> PCI: More strict checking of valid range for bridge
> PCI: Don't shrink too much for hotplug bridge
Yinghai,
For some functions, such as probe_resource() would you mind add some
comments? Such as explain the parameter usage.
That would help for reading the function.
--
Richard Yang
Help you, Help me
On Wed, May 2, 2012 at 11:54 PM, Richard Yang
<[email protected]> wrote:
> On Wed, Apr 25, 2012 at 09:28:19AM -0700, Yinghai Lu wrote:
>>On Wed, Apr 25, 2012 at 2:47 AM, Wei Yang <[email protected]> wrote:
>>>> busn_alloc patchset should address your concern.
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>>>> for-pci-busn-alloc
>
> For some functions, such as probe_resource() would you mind add some
> comments? ?Such as explain the parameter usage.
> That would help for reading the function.
I updated for-pci-busn-alloc branch with updating of probe_resource()...
and removing bus->secondary and subordinate.
Please check if you can understand it ...
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=7de8df57b223d54af95ffe67f8da2dd39a265971
Thanks
Yinghai
On Thu, May 03, 2012 at 01:33:17AM -0700, Yinghai Lu wrote:
>On Wed, May 2, 2012 at 11:54 PM, Richard Yang
><[email protected]> wrote:
>> On Wed, Apr 25, 2012 at 09:28:19AM -0700, Yinghai Lu wrote:
>>>On Wed, Apr 25, 2012 at 2:47 AM, Wei Yang <[email protected]> wrote:
>>>>> busn_alloc patchset should address your concern.
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>>>>> for-pci-busn-alloc
>>
>> For some functions, such as probe_resource() would you mind add some
>> comments? ?Such as explain the parameter usage.
>> That would help for reading the function.
>
>I updated for-pci-busn-alloc branch with updating of probe_resource()...
>and removing bus->secondary and subordinate.
>
You mean you remove the bus->secondary field?
So the pci_bus->number hold the bus number?
I think this is a huge work.
>Please check if you can understand it ...
>
>http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=7de8df57b223d54af95ffe67f8da2dd39a265971
Some question:
+static resource_size_t __find_res_top_free_size(struct resource *res,
+ int skip_nr)
+{
+ resource_size_t n_size;
+ struct resource tmp_res;
+
+ */
+ * find out free number below res->end that we can use.
+ * res->start to res->start + skip_nr - 1 can not be used.
+ */
+ n_size = resource_size(res);
+ if (n_size <= skip_nr)
+ return 0;
+
+ n_size -= skip_nr;
+ memset(&tmp_res, 0, sizeof(struct resource));
+ while (n_size > 0) {
+ int ret;
+
+ ret = __allocate_resource(res, &tmp_res, n_size,
+ res->end - n_size + skip_nr, res->end,
+ 1, NULL, NULL, false);
+ if (ret == 0) {
+ __release_resource(&tmp_res);
+ break;
+ }
+ n_size--;
+ }
+
+ return n_size;
+}
So this is trying to find out the biggest free space of res?
On the right side?
For example we have , res like
90-150
105-140
The __find_res_top_free_size() will return 10 instead of 15.
So this is the design decision to find the right side free resouce not
the left side?
>
>Thanks
>
>Yinghai
--
Richard Yang
Help you, Help me
On Thu, May 3, 2012 at 7:47 PM, Richard Yang <[email protected]> wrote:
> On Thu, May 03, 2012 at 01:33:17AM -0700, Yinghai Lu wrote:
>>On Wed, May 2, 2012 at 11:54 PM, Richard Yang
>><[email protected]> wrote:
>>> On Wed, Apr 25, 2012 at 09:28:19AM -0700, Yinghai Lu wrote:
>>>>On Wed, Apr 25, 2012 at 2:47 AM, Wei Yang <[email protected]> wrote:
>>>>>> busn_alloc patchset should address your concern.
>>>>>>
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>>>>>> for-pci-busn-alloc
>>>
>>> For some functions, such as probe_resource() would you mind add some
>>> comments? ?Such as explain the parameter usage.
>>> That would help for reading the function.
>>
>>I updated for-pci-busn-alloc branch with updating of probe_resource()...
>>and removing bus->secondary and subordinate.
>>
> You mean you remove the bus->secondary field?
> So the pci_bus->number hold the bus number?
> I think this is a huge work.
>>Please check if you can understand it ...
>>
>>http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=7de8df57b223d54af95ffe67f8da2dd39a265971
> Some question:
>
> +static resource_size_t __find_res_top_free_size(struct resource *res,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int skip_nr)
> +{
> + ? ? ? resource_size_t n_size;
> + ? ? ? struct resource tmp_res;
> +
> + ? ? ? */
> + ? ? ? ?* ? find out free number below res->end that we can use.
> + ? ? ? ?* ? ? ?res->start to res->start + skip_nr - 1 can not be used.
> + ? ? ? ?*/
> + ? ? ? n_size = resource_size(res);
> + ? ? ? if (n_size <= skip_nr)
> + ? ? ? ? ? ? ? return 0;
> +
> + ? ? ? n_size -= skip_nr;
> + ? ? ? memset(&tmp_res, 0, sizeof(struct resource));
> + ? ? ? while (n_size > 0) {
> + ? ? ? ? ? ? ? int ret;
> +
> + ? ? ? ? ? ? ? ret = __allocate_resource(res, &tmp_res, n_size,
> + ? ? ? ? ? ? ? ? ? ? ? res->end - n_size + skip_nr, res->end,
> + ? ? ? ? ? ? ? ? ? ? ? 1, NULL, NULL, false);
> + ? ? ? ? ? ? ? if (ret == 0) {
> + ? ? ? ? ? ? ? ? ? ? ? __release_resource(&tmp_res);
> + ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? n_size--;
> + ? ? ? }
> +
> + ? ? ? return n_size;
> +}
> So this is trying to find out the biggest free space of res?
> On the right side?
>
> For example we have , res like
> ? 90-150
> ? ? ? ?105-140
> The __find_res_top_free_size() will return 10 instead of 15.
> So this is the design decision to find the right side free resouce not
> the left side?
__find_res_top_free_size() is called by probe_resource().
probe_resource will return [91-104].
Thanks
Yinghai
On Thu, May 03, 2012 at 08:15:29PM -0700, Yinghai Lu wrote:
>>>
>>>I updated for-pci-busn-alloc branch with updating of probe_resource()...
>>>and removing bus->secondary and subordinate.
>>>
>> You mean you remove the bus->secondary field?
>> So the pci_bus->number hold the bus number?
>> I think this is a huge work.
>>>Please check if you can understand it ...
>>>
>>>http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=7de8df57b223d54af95ffe67f8da2dd39a265971
>> Some question:
>>
>> +static resource_size_t __find_res_top_free_size(struct resource *res,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int skip_nr)
>> +{
>> + ? ? ? resource_size_t n_size;
>> + ? ? ? struct resource tmp_res;
>> +
>> + ? ? ? */
>> + ? ? ? ?* ? find out free number below res->end that we can use.
>> + ? ? ? ?* ? ? ?res->start to res->start + skip_nr - 1 can not be used.
>> + ? ? ? ?*/
>> + ? ? ? n_size = resource_size(res);
>> + ? ? ? if (n_size <= skip_nr)
>> + ? ? ? ? ? ? ? return 0;
>> +
>> + ? ? ? n_size -= skip_nr;
>> + ? ? ? memset(&tmp_res, 0, sizeof(struct resource));
>> + ? ? ? while (n_size > 0) {
>> + ? ? ? ? ? ? ? int ret;
>> +
>> + ? ? ? ? ? ? ? ret = __allocate_resource(res, &tmp_res, n_size,
>> + ? ? ? ? ? ? ? ? ? ? ? res->end - n_size + skip_nr, res->end,
>> + ? ? ? ? ? ? ? ? ? ? ? 1, NULL, NULL, false);
>> + ? ? ? ? ? ? ? if (ret == 0) {
>> + ? ? ? ? ? ? ? ? ? ? ? __release_resource(&tmp_res);
>> + ? ? ? ? ? ? ? ? ? ? ? break;
>> + ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? n_size--;
>> + ? ? ? }
>> +
>> + ? ? ? return n_size;
>> +}
>> So this is trying to find out the biggest free space of res?
>> On the right side?
>>
>> For example we have , res like
>> ? 90-150
>> ? ? ? ?105-140
>> The __find_res_top_free_size() will return 10 instead of 15.
>> So this is the design decision to find the right side free resouce not
>> the left side?
>
> __find_res_top_free_size() is called by probe_resource().
>
>probe_resource will return [91-104].
Hmm... I think the result is returned by this while loop.
+ while (n_size >= needed_size) {
+ ret = allocate_resource(b_res, busn_res, n_size,
+ b_res->start + skip_nr, b_res->end,
+ 1, NULL, NULL);
+ if (!ret)
+ return ret;
+ n_size--;
+ }
__find_res_top_free_size() is not called.
BTW, even if this value is returned by __find_res_top_free_size(), or
returned after this function is called, the purpose of the
__find_res_top_free_size() is to get the biggest free space under the
first parameter?
>
>Thanks
>
>Yinghai
--
Richard Yang
Help you, Help me
On Thu, May 3, 2012 at 9:52 PM, Richard Yang <[email protected]> wrote:
>
> BTW, even if this value is returned by __find_res_top_free_size(), or
> returned after this function is called, the purpose of the
> __find_res_top_free_size() is to get the biggest free space under the
> first parameter?
__find_res_top_free_size() is used to get size just under top, and
then use it to calculate size above top that need to be extended.
at last will combine free size under top and allocated size above top
and return.
Yinghai
On Fri, May 04, 2012 at 10:37:08AM -0700, Yinghai Lu wrote:
>On Thu, May 3, 2012 at 9:52 PM, Richard Yang <[email protected]> wrote:
>>
>> BTW, even if this value is returned by __find_res_top_free_size(), or
>> returned after this function is called, the purpose of the
>> __find_res_top_free_size() is to get the biggest free space under the
>> first parameter?
>
>__find_res_top_free_size() is used to get size just under top, and
>then use it to calculate size above top that need to be extended.
>
>at last will combine free size under top and allocated size above top
>and return.
Yes, I get the general idea.
then I want to confirm which size __find_res_top_free_size() will return.
Come to the previous question, for one resource like this.
res = 90-150
->child 105-140
We call __find_res_top_free_size(res, 1);
This function should return which size? 10? 15? or 25?
>From the code
+ ret = __allocate_resource(res, &tmp_res, n_size,
+ res->end - n_size + skip_nr, res->end,
+ 1, NULL, NULL, false);
I think it will check the free space near the end of res.
I did one test on __find_res_top_free_size(res, 1) of this example.
And returned 10. Which means, it find the free space (141-150).
So I want to confirm this function really returns the size of free space
at the end of the res. not the biggest one or the sum.
>
>Yinghai
--
Richard Yang
Help you, Help me
On Sun, May 6, 2012 at 8:17 AM, Richard Yang <[email protected]> wrote:
> On Fri, May 04, 2012 at 10:37:08AM -0700, Yinghai Lu wrote:
>>On Thu, May 3, 2012 at 9:52 PM, Richard Yang <[email protected]> wrote:
>>>
>>> BTW, even if this value is returned by __find_res_top_free_size(), or
>>> returned after this function is called, the purpose of the
>>> __find_res_top_free_size() is to get the biggest free space under the
>>> first parameter?
>>
>>__find_res_top_free_size() is used to get size just under top, ?and
>>then use it to calculate size above top that need to be extended.
>>
>>at last will combine free size under top and allocated size above top
>>and return.
> Yes, I get the general idea.
>
> then I want to confirm which size __find_res_top_free_size() will return.
>
> Come to the previous question, for one resource like this.
> res = ? 90-150
> ? ?->child ? ? ?105-140
> We call __find_res_top_free_size(res, 1);
> This function should return which size? ?10? 15? or 25?
>
> From the code
> + ? ? ? ? ? ? ? ret = __allocate_resource(res, &tmp_res, n_size,
> + ? ? ? ? ? ? ? ? ? ? ? res->end - n_size + skip_nr, res->end,
> + ? ? ? ? ? ? ? ? ? ? ? 1, NULL, NULL, false);
> I think it will check the free space near the end of res.
yes. it is 15, [141-150]
On Sun, May 6, 2012 at 9:35 AM, Yinghai Lu <[email protected]> wrote:
> On Sun, May 6, 2012 at 8:17 AM, Richard Yang <[email protected]> wrote:
>> On Fri, May 04, 2012 at 10:37:08AM -0700, Yinghai Lu wrote:
>>>On Thu, May 3, 2012 at 9:52 PM, Richard Yang <[email protected]> wrote:
>>>>
>>>> BTW, even if this value is returned by __find_res_top_free_size(), or
>>>> returned after this function is called, the purpose of the
>>>> __find_res_top_free_size() is to get the biggest free space under the
>>>> first parameter?
>>>
>>>__find_res_top_free_size() is used to get size just under top, ?and
>>>then use it to calculate size above top that need to be extended.
>>>
>>>at last will combine free size under top and allocated size above top
>>>and return.
>> Yes, I get the general idea.
>>
>> then I want to confirm which size __find_res_top_free_size() will return.
>>
>> Come to the previous question, for one resource like this.
>> res = ? 90-150
>> ? ?->child ? ? ?105-140
>> We call __find_res_top_free_size(res, 1);
>> This function should return which size? ?10? 15? or 25?
>>
>> From the code
>> + ? ? ? ? ? ? ? ret = __allocate_resource(res, &tmp_res, n_size,
>> + ? ? ? ? ? ? ? ? ? ? ? res->end - n_size + skip_nr, res->end,
>> + ? ? ? ? ? ? ? ? ? ? ? 1, NULL, NULL, false);
>> I think it will check the free space near the end of res.
>
> yes. it is 15, [141-150]
should 10, aka [141-150]
On Sun, May 06, 2012 at 09:36:35AM -0700, Yinghai Lu wrote:
>On Sun, May 6, 2012 at 9:35 AM, Yinghai Lu <[email protected]> wrote:
>> On Sun, May 6, 2012 at 8:17 AM, Richard Yang <[email protected]> wrote:
>>> On Fri, May 04, 2012 at 10:37:08AM -0700, Yinghai Lu wrote:
>>>>On Thu, May 3, 2012 at 9:52 PM, Richard Yang <[email protected]> wrote:
>>>>>
>>>>> BTW, even if this value is returned by __find_res_top_free_size(), or
>>>>> returned after this function is called, the purpose of the
>>>>> __find_res_top_free_size() is to get the biggest free space under the
>>>>> first parameter?
>>>>
>>>>__find_res_top_free_size() is used to get size just under top, ?and
>>>>then use it to calculate size above top that need to be extended.
>>>>
>>>>at last will combine free size under top and allocated size above top
>>>>and return.
>>> Yes, I get the general idea.
>>>
>>> then I want to confirm which size __find_res_top_free_size() will return.
>>>
>>> Come to the previous question, for one resource like this.
>>> res = ? 90-150
>>> ? ?->child ? ? ?105-140
>>> We call __find_res_top_free_size(res, 1);
>>> This function should return which size? ?10? 15? or 25?
>>>
>>> From the code
>>> + ? ? ? ? ? ? ? ret = __allocate_resource(res, &tmp_res, n_size,
>>> + ? ? ? ? ? ? ? ? ? ? ? res->end - n_size + skip_nr, res->end,
>>> + ? ? ? ? ? ? ? ? ? ? ? 1, NULL, NULL, false);
>>> I think it will check the free space near the end of res.
>>
>> yes. it is 15, [141-150]
>
>should 10, aka [141-150]
Thanks,
so this free space will be combined with the free space got from
parent, form a big space to meet the requirement.
This is the general idea about probe_resource()?
And this is the design decision to find the free space at the end
of top, even at the start we have more free space?
--
Richard Yang
Help you, Help me
On Sun, May 6, 2012 at 6:17 PM, Richard Yang <[email protected]> wrote:
> so this free space will be combined with the free space got from
> parent, form a big space to meet the requirement.
>
> This is the general idea about probe_resource()?
>
> And this is the design decision to find the free space at the end
> of top, even at the start we have more free space?
no, probe_resource will get from start if space is big enough.
if not, it will try to extend top.
Yinghai
On Sun, May 06, 2012 at 07:04:09PM -0700, Yinghai Lu wrote:
>On Sun, May 6, 2012 at 6:17 PM, Richard Yang <[email protected]> wrote:
>> so this free space will be combined with the free space got from
>> parent, form a big space to meet the requirement.
>>
>> This is the general idea about probe_resource()?
>>
>> And this is the design decision to find the free space at the end
>> of top, even at the start we have more free space?
>
>no, probe_resource will get from start if space is big enough.
>
>if not, it will try to extend top.
Hmm... for example we still have this
parent[70-160]
brother1[70-80] res[90-150] brother2[151-160]
->child[105-140]
if we call probe_resource(res, new_res, 16, par, 1, 0xff,
IORESOURCE_PCI_FIXED);
I think this call is used to allocate a res of size 16 under res.
When there is no enough free space, it will expend res, and res->parent.
While in this situation, res doesn't have enough free space. so it need
to expend itself.
In the probe_resource() it tries to extend res on the right side.
So even there is enough space between brother1 and res, I think the
probe_resource() will not return 0.
Do you think my analysis is correct?
>
>Yinghai
--
Richard Yang
Help you, Help me
On Mon, May 7, 2012 at 7:46 PM, Richard Yang <[email protected]> wrote:
> On Sun, May 06, 2012 at 07:04:09PM -0700, Yinghai Lu wrote:
>>On Sun, May 6, 2012 at 6:17 PM, Richard Yang <[email protected]> wrote:
>>> so this free space will be combined with the free space got from
>>> parent, form a big space to meet the requirement.
>>>
>>> This is the general idea about probe_resource()?
>>>
>>> And this is the design decision to find the free space at the end
>>> of top, even at the start we have more free space?
>>
>>no, probe_resource will get from start if space is big enough.
>>
>>if not, it will try to extend top.
>
> Hmm... for example we still have this
> ? ? ? ? ? ? ? parent[70-160]
> brother1[70-80] ?res[90-150] ?brother2[151-160]
> ? ? ? ? ? ? ? ? ? ->child[105-140]
>
> if we call probe_resource(res, new_res, 16, par, 1, 0xff,
> IORESOURCE_PCI_FIXED);
>
> I think this call is used to allocate a res of size 16 under res.
> When there is no enough free space, it will expend res, and res->parent.
>
> While in this situation, res doesn't have enough free space. so it need
> to expend itself.
>
> In the probe_resource() it tries to extend res on the right side.
> So even there is enough space between brother1 and res, I think the
> probe_resource() will not return 0.
>
> Do you think my analysis is correct?
it will reduce needed size one by one. so at last it will return
[91, 104]
Yinghai
On Mon, May 07, 2012 at 08:42:59PM -0700, Yinghai Lu wrote:
>>>no, probe_resource will get from start if space is big enough.
>>>
>>>if not, it will try to extend top.
>>
>> Hmm... for example we still have this
>> ? ? ? ? ? ? ? parent[70-160]
>> brother1[70-80] ?res[90-150] ?brother2[151-160]
>> ? ? ? ? ? ? ? ? ? ->child[105-140]
>>
>> if we call probe_resource(res, new_res, 16, par, 1, 0xff,
>> IORESOURCE_PCI_FIXED);
>>
>> I think this call is used to allocate a res of size 16 under res.
>> When there is no enough free space, it will expend res, and res->parent.
>>
>> While in this situation, res doesn't have enough free space. so it need
>> to expend itself.
>>
>> In the probe_resource() it tries to extend res on the right side.
>> So even there is enough space between brother1 and res, I think the
>> probe_resource() will not return 0.
>>
>> Do you think my analysis is correct?
>
>it will reduce needed size one by one. so at last it will return
>[91, 104]
Yes, agree. This is the current behavior.
While in this case.
? ? ? ? ? ? ? 70-160]
brother1[70-80] ?res[90-150] ?brother151-160]
? ? ? ? ? ? ? ? ? ->child
There is free space between 81-89, and 90-104. These two free range add
up to 25, which is more than the required space, 16.
If we have this resource tree.
? ? ? ? ?parent[70-180]
brother1[70-80] ?re[90-150] ?brothr2[170-180]
? ? ? ? ? ? ? ? d[105-140]
There are enough free space between res and brother2.
Then probe_resource will return [141-156] with size 16.
And also expend res.
So I mean this is the design decision to not count in the free space on
the left? Even there is enough free space?
>
>Yinghai
--
Richard Yang
Help you, Help me
On Wed, May 9, 2012 at 8:35 PM, Richard Yang <[email protected]> wrote:
> On Mon, May 07, 2012 at 08:42:59PM -0700, Yinghai Lu wrote:
>>>>no, probe_resource will get from start if space is big enough.
>>>>
>>>>if not, it will try to extend top.
>>>
>>> Hmm... for example we still have this
>>> ? ? ? ? ? ? ? parent[70-160]
>>> brother1[70-80] ?res[90-150] ?brother2[151-160]
>>> ? ? ? ? ? ? ? ? ? ->child[105-140]
>>>
>>> if we call probe_resource(res, new_res, 16, par, 1, 0xff,
>>> IORESOURCE_PCI_FIXED);
>>>
>>> I think this call is used to allocate a res of size 16 under res.
>>> When there is no enough free space, it will expend res, and res->parent.
>>>
>>> While in this situation, res doesn't have enough free space. so it need
>>> to expend itself.
>>>
>>> In the probe_resource() it tries to extend res on the right side.
>>> So even there is enough space between brother1 and res, I think the
>>> probe_resource() will not return 0.
>>>
>>> Do you think my analysis is correct?
>>
>>it will reduce needed size one by one. so at last it will return
>>[91, 104]
> Yes, agree. This is the current behavior.
>
> While in this case.
> ?? ? ? ? ? ? ? 70-160]
> ?brother1[70-80] ?res[90-150] ?brother151-160]
> ?? ? ? ? ? ? ? ? ? ->child
>
> There is free space between 81-89, and 90-104. These two free range add
> up to 25, which is more than the required space, 16.
>
> If we have this resource tree.
> ?? ? ? ? ?parent[70-180]
> ?brother1[70-80] ?re[90-150] ?brothr2[170-180]
> ?? ? ? ? ? ? ? ? d[105-140]
>
> There are enough free space between res and brother2.
> Then probe_resource will return [141-156] with size 16.
> And also expend res.
>
> So I mean this is the design decision to not count in the free space on
> the left? Even there is enough free space?
We can not extend start.
when we have bridge using [90, 150] all children devices will be on bus 90.
if change the bridge to use low like 81, then all device need to
remove and rescan them.
also keep the old bus number is safer.
Yinghai
On Wed, May 09, 2012 at 10:42:06PM -0700, Yinghai Lu wrote:
>
>We can not extend start.
>
>when we have bridge using [90, 150] all children devices will be on bus 90.
>if change the bridge to use low like 81, then all device need to
>remove and rescan them.
>
>also keep the old bus number is safer.
Oh, got it.
>
>Yinghai
--
Richard Yang
Help you, Help me