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

[Scott Wood]

On 08/08/2012 10:48 PM, Jia Hongtao-B38951 wrote:
> 
> 
>> -----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. 

How is it an accident?  It's a perfectly legitimate situation.

> 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".

It's not equivalent because I didn't try to convert the ge_imp3a board,
and if I did I would have added special code to the ge_imp3a board to
set the fsl_pci_primary before calling fsl_pci_init().

-Scott