On Wed, 2021-02-24 at 20:25 +0000, Christoph Hellwig wrote:

On Wed, Feb 24, 2021 at 08:55:10AM -0800, Florian Fainelli wrote:

quoted

quoted

Working around kernel I/O accessors is all very well, but another
concern for PCI in particular is when things like framebuffer memory can
get mmap'ed into userspace (or even memremap'ed within the kernel). Even
in AArch32, compiled code may result in 64-bit accesses being generated
depending on how the CPU and interconnect handle LDRD/STRD/LDM/STM/etc.,
so it's basically not safe to ever let that happen at all.

Agreed, this makes finding a generic solution a tiny bit harder. Do you
have something in mind Nicolas?

The only workable solution is a new

bool 64bit_mmio_supported(void)

check that is used like:

	if (64bit_mmio_supported())
		readq(foodev->regs, REG_OFFSET);
	else
		lo_hi_readq(foodev->regs, REG_OFFSET);

where 64bit_mmio_supported() return false for all 32-bit kernels,
true for all non-broken 64-bit kernels and is an actual function
for arm64 multiplatforms builds that include te RPi quirk.

The above would then replace the existing magic from the
<linux/io-64-nonatomic-lo-hi.h> and <linux/io-64-nonatomic-hi-lo.h>
headers.

Is it completely impossible to do 64-bit cycles with this host bridge?

I'm now having nasty flashbacks to an SH platform with a host bridge
that screwed up byte access for direct MMIO — but *could* do those MMIO
cycles accurately if we did them through an indirect method similar to
config cycles. Is there any such mechanism on the offending hardware?