Re: [PATCH 08/14] pci: update bridge res to get more big range inpci assign unssign

[Jesse Barnes]

On Fri, 15 Jan 2010 13:12:39 -0800
Yinghai Lu <yinghai@xxxxxxxxxx> wrote:

> On 01/15/2010 11:12 AM, Jesse Barnes wrote:
> > On Tue, 22 Dec 2009 15:02:28 -0800
> > Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
> > 
> >> BIOS separate IO range between several IOHs, and on some slots,
> >> BIOS assign the resource to the bridge, but stop assigning
> >> resource to the device under that bridge, because the device need
> >> big resource.
> >>
> >> 1. pci assign unassign and record the failed device resource.
> >> 2. clear the BIOS assigned resource of the parent bridge of fail
> >> device 3. go back and call pci assign unsigned
> >> 4. if it still fail, will go up more bridges. and clear and try
> >> again.
> >>
> >> use pci_try_num to control back track bridge levels.
> >>
> >> -v2: update it with resource_list_x
> >> -v3: make pci_try_num default to 1. and when pci_try_num is set to
> >> more than 1 will check it with max_depth, and adjust that to make
> >> sure it is bigger enough
> > 
> > I really don't like the 'try' argument.  Either we can assign the
> > resource or not; 'try=' just makes the whole thing scarier, as if we
> > expect problems if we release too many resources.  If that's the
> > case, then the whole approach must be flawed, since it means we're
> > not taking into account some resources, or we're missing something
> > about the system configuration.
> 
> before this patchset, acctually try = 1, and will not touch pci
> bridge resource if that are assigned by BIOS.
> 
> with this patchset, try = 1, will just like the old ways.
> try = 2, it will find the deepest bridge, and increase the try.

Yeah, I know what it's supposed to do, I just don't like it in
principle.  We should be getting this right in the first place, not
providing the user magical options.  For debugging maybe it's ok, but
it should at least be called pci_reassign_depth= or something instead
to make it clear.  I guess the options would be =leaf, =<num>, or =top?

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/