[PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code

[Jia Hongtao-B38951]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, August 09, 2012 12:02 AM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev at lists.ozlabs.org;
> galak at kernel.crashing.org; Li Yang-R58472
> Subject: Re: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie
> initialization code
> 
> On 08/08/2012 04:39 AM, Jia Hongtao-B38951 wrote:
> >
> >
> >> -----Original Message-----
> >> From: Wood Scott-B07421
> >> Sent: Tuesday, August 07, 2012 11:29 PM
> >> To: Jia Hongtao-B38951
> >> Cc: Wood Scott-B07421; linuxppc-dev at lists.ozlabs.org;
> >> galak at kernel.crashing.org; Li Yang-R58472
> >> Subject: Re: [PATCH V5 3/3] powerpc/fsl-pci: Unify pci/pcie
> >> initialization code
> >>
> >> On 08/07/2012 03:09 AM, Jia Hongtao-B38951 wrote:
> >>> I am really not sure that all boards need primary bus. Could you
> >>> give me the link of discussion about primary that you mentioned?
> >>
> >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-June/098586.html
> >>
> >> -Scott
> >
> >
> > It seems in qemu isa_io_base must be non-zero.
> 
> In all cases.  It just shows up worse under QEMU because of a different
> issue.
> 
> > If there is no isa bridge should isa_io_base be non-zero for other
> boards?
> 
> Yes, until the bugs are fixed.
> 
> > If not maybe we should fix qemu bug.
> 
> If you want to try to make QEMU accept I/O BARs with address zero, go
> ahead, but you don't get to assume that someone else will do it, we still
> need to be compatible with older QEMUs (this bug is not so severe that
> compatibility is unreasonable), and it still doesn't address the fact
> that things are not functioning as designed.  IIRC there are some real
> hardware PCI cards that don't like getting an address of zero either.
> 
> > Or "quick fix" in the link is a workaround.
> 
> I think that "quick fix" may have problems if there is a primary bus but
> it's not the first one detected.  In any case, any fix or workaround has
> to happen before you make changes that rely on it.
> 
> -Scott

If there is no primary assigned and accidently the primary is not the
first one this "quick fix" may have problem. But this -accident- only happened
in ge_imp3a board if I didn't miss other boards. 

So if there is no primary assigned but the primary is the first bus detected
this "quick fix" is right. That means the "quick fix" is the equivalent
substitution for "arbitrarily designate one as primary".

Maybe we can use the "quick fix" and fix ge_imp3a as an exceptional case.

-Hongtao.