[PATCH] arm64: Enable PCI write-combine resources under sysfs
benh at kernel.crashing.org
Thu Sep 3 18:26:23 EDT 2020
On Thu, 2020-09-03 at 12:08 +0100, Lorenzo Pieralisi wrote:
> "Additional Guidance on the Prefetchable Bit in Memory Space BARs"
> I read it 100 times and I still have no idea how it can be
> it sorts of acknowledges that read side-effects memory can be marked
> as a prefetchable BAR *if* the system meets some criteria.
> As if endpoint designers knew the system where their endpoint is
> plugged into (+ bit (3) in a BAR is read-only).
> I think that that implementation note must be removed from the
> specifications - if anyone dares to follow it this whole
> WC resource mapping can trigger trouble.
Ah that one ! Yes you are right its completely broken.
This part of the spec aims at working around the fact that bridges only
have 64-bit prefetchable windows, so anything non-pref has to go below
a 32-bit bridge window (effectively making most 64-bit non-pref BARs a
pointless waste of silicon).
The right fix of course would have been to create a new type of bridge
window. But PCI...
If you're going to mess around with the SIG, I would suggest that a
better approach short of the above would be to allow system software to
put 64-bit non-pref BARs below bridge pref windows on PCIe (provided
the various otehr restrictions in that note are honored such as bridges
not prefetching) and leave it at that. (Unless they already do
somewhere else, I forgot ...).
This should be sufficient to address the space concern without killing
the meaning of the prefetchable bit.
As for enabling the _wc files in sysfs, well, you need some serious
priviledge to be able to access them, so I don't see a big issue
allowing them to exist when "prefetchable" is set regardless of that
rule. The Mellanox case might be different.
More information about the linux-arm-kernel