Re: Data corruption on i.MX6 IPU in arm_copy_from_user()

[Russell King (Oracle)]

On Fri, May 28, 2021 at 12:02:52PM +0200, Krzysztof Hałasa wrote:
> "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx> writes:
> 
> > In any case, looking at the architecture reference manual, LDM is
> > permitted on device and strongly ordered mappings, and the memory
> > subsystem is required to decompose it into a series of 32-bit accesses.
> > So, it sounds to me like there could be a hardware bug in the buses/IPU
> > causing this.
> 
> It seems so.
> 
> I modified the kernel IPU module a bit, initialized a bunch of IPU
> registers to known values (1..0xD). Results (from 1 to 13 IPU
> registers) obtained with different instructions:
> 
> readl(13 consecutive registers): CSI = 1 2 3 4 5 6 7 8 9 A B C D
> 1 = register #0 and so on - readl() results are obviously correct.
> 
> LDM1:  1 (not corrupted)
> LDM2:  1 3
> LDM3:  1 3 4
> LDM4:  2 3 4 4
> LDM5:  1 3 4 5 6
> LDM6:  1 3 4 5 6 7
> LDM7:  1 3 4 5 6 7 8
> LDM8:  2 3 4 5 6 7 8 8
> LDM9:  1 3 4 5 6 7 8 9 A
> LDM10: 1 3 4 5 6 7 8 9 A B
> LDM11: 1 3 4 5 6 7 8 9 A B C
> LDM12: 1 3 4 5 6 7 8 9 A B C D

That's rather sad, and does look very much like a hardware bug.

The question is what to do about it... there's Linus' "do not break
userspace" edict and that's exactly what this change has done. So I
suppose we're going to have to revert the change and put up with
everything being slightly slower on arm32 than it otherwise would
have been. That probably means we'll end up with almost every kernel
tree out there carrying a revert of the revert to work around the
fact that seemingly NXP broke their hardware - which itself is not
a good idea. I guess we're just going to have to put up with that.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!