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: > > > 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?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
