Re: [PATCH] Copy bus scanning workaround from ARM Juno PCIe driver.

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 26 May 2017 at 16:50, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Wed, May 24, 2017 at 07:03:10AM -0700, Ard Biesheuvel wrote:
>> (+ Leif)
>>
>> On 24 May 2017 at 01:34, Scott Telford <stelford@cadence.com> wrote:
>> > Hi Ard,
>> >
>> > Firstly, this patch was meant for my edk2-staging branch, not
>> > mainline edk2 - sorry, forgot to edit the subject line!
>>
>> Ah ok. In that case, do whatever you like :-)
>
> Well, let's try to get keep the staging branch in a state that doesn't
> require too heavy reworking before final upstreaming.
>
>> > The issue is that, without this workaround, PCI(e) bridges and
>> > devices will be detected multiple times during bus scanning,
>> > e.g. a bridge at bus 1 device 0 will also be seen at bus 1 device
>> > 1, bus 1 device 2 etc and hence all the devices on the other side
>> > of the bridge will be duplicated too. I copied this workaround
>> > from the old Juno PCIe driver as I was seeing the same problem
>> > when I was testing the Cadence PCIe host bridge library I have
>> > been working on. I agree there should probably be a more elegant
>> > solution, but I don't know the generic PCI driver code well enough
>> > to suggest one at the moment.
>>
>> As I said, the workaround belongs in PciExpressLib. You can just clone
>> that and put the workaround in there.
>>
>> Interestingly, though, this PCIe IP works fine with the generic ECAM
>> driver in Linux, so I wonder what the difference is.
>>
>> Leif, were you aware of this issue?
>
> I was not aware of this issue.
> So a clone of PciExpressLib, whilst suboptimal, sounds like the way to
> go for now.
>

I'd still like to understand why this issue does not occur under
Linux, or if it does occur, if we need an ECAM quirk for Juno to work
around it.

Could you give an example of which hardware combination triggers this issue?