From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C4D552095A364 for ; Fri, 26 May 2017 10:37:49 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id c15so474023ith.0 for ; Fri, 26 May 2017 10:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cm6pnyMByvh3aKfo07W/uZT2eog7hnI24pAK3BfZsqY=; b=ZSOY+sKGJptSGm9H/PWgnu9FuLdGQRUW8aYtUCN8MwUt87YsH0IqMd1S15HoJaJmlo YzWV5ppi3dCM1K8QhpHK9IEww93jcemh78VtGojuHeh/aaYYMhsf4qe3R/LFMtehtwkg cVkyjM6c2KaexLCC2GBrA9dFBce8J8p3JVUXA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cm6pnyMByvh3aKfo07W/uZT2eog7hnI24pAK3BfZsqY=; b=k1GX79ir1amuew3+aECv7xEK2gZOUfcAw50Ve51XOd5fettsTs42Dqw4GtNcpQLJfJ CXr2qT3OlIPmkUD5jFMCyudCC8tC3+lFSpsqbS+aQcmngKsmkFMBHJlT1E6Gq9rR9hTj xii+mXNvJNlvlm8FvENqCjUJroHYu3ypSBL5d0Fjg9kNk7ix9CHoMvLtgzh4G9wH4OeC fx24XXER55V71eHjEQJXNKfJj3Ysegy72CNNLZPGolMM+3dC2gYA1pIgz9FOumghvAFf GGeF8ua54z3JdWK9VWaE3XJZL0eMeHwm48JkhdtyzwJ64Kipj+50pX8gKwDEEay5kBqI QYIw== X-Gm-Message-State: AODbwcCUbQix4QvZCrE6QduLNtg9hFDxrqEachx/xQ2TRTQ5OELuDbyF N6F3aeyxUEyS5RqPKz//1svD/SnZP8HS X-Received: by 10.36.105.71 with SMTP id e68mr4220590itc.6.1495820268804; Fri, 26 May 2017 10:37:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.24 with HTTP; Fri, 26 May 2017 10:37:48 -0700 (PDT) In-Reply-To: <20170526145029.GM32240@bivouac.eciton.net> References: <1495556147-6883-1-git-send-email-stelford@cadence.com> <20170526145029.GM32240@bivouac.eciton.net> From: Ard Biesheuvel Date: Fri, 26 May 2017 19:37:48 +0200 Message-ID: To: Leif Lindholm Cc: Scott Telford , "edk2-devel@lists.01.org" , "Tian, Feng" , "Zeng, Star" Subject: Re: [PATCH] Copy bus scanning workaround from ARM Juno PCIe driver. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 17:37:50 -0000 Content-Type: text/plain; charset="UTF-8" On 26 May 2017 at 16:50, Leif Lindholm wrote: > On Wed, May 24, 2017 at 07:03:10AM -0700, Ard Biesheuvel wrote: >> (+ Leif) >> >> On 24 May 2017 at 01:34, Scott Telford 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?