From: Yinghai Lu <yinghai@xxxxxxxxxx> Date: Tue, 31 Mar 2015 11:16:11 -0700 > On Tue, Mar 31, 2015 at 8:06 AM, David Miller <davem@xxxxxxxxxxxxx> wrote: >> Your patch only allows the condition behind resources that have 64-bits >> of significance, but that is not what the document above says about >> when this situation is allowed. >> >> Please implement the check either exactly as stated in the errata >> document, or more loosely if that is not possible, rather than more >> strictly than allowed. >> >> Your overly strict and restrictive checks are what got us into this >> predicament in the first place. :-( > > From that errata: > --- > Here are criteria that are sufficient to guarantee correctness for a > given candidate BAR: > > The entire path from the host to the adapter is over PCI Express. > > No conventional PCI or PCI-X devices do peer-t o-peer reads to the > range mapped by the BAR. > > The PCI Express Host Bridge does no byte merging. (This is believed to > be true on most > platforms.) > > Any locations with read side-effects are never the target of Memory > Reads with the TH bit Set. > See Section 2.2.5 > --- > > We can verify first one that we have all pcie device all the way to > the hostbridge. > > But we can not verify or guarantee other three. Lack of peer-to-peer reads we can assume, the byte merging we can add as a per-controller attribute in the future if it turns out there are some that do and it matters (I doubt this will ever be necessary) and the side-effect issue is outside the scope of the PCI layer. > System should get better about the constraints with system design. > So if it would assign 64bit (and above 4G) mmio to those non-pref 64bit BAR, > that means it already make sure system design will follow those criteria. > and then we can safely set pref bit in resource flags. I totally disagree, I think your test is too stringent and should be significantly relaxed if not removed entirely. ��.n��������+%������w��{.n�����{���"�)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥