linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Krzysztof Hałasa" <khalasa@piap.pl>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: Data corruption on i.MX6 IPU in arm_copy_from_user()
Date: Fri, 28 May 2021 15:35:44 +0100	[thread overview]
Message-ID: <20210528143544.GQ30436@shell.armlinux.org.uk> (raw)
In-Reply-To: <m3h7intbub.fsf@t19.piap.pl>

On Fri, May 28, 2021 at 12:02:52PM +0200, Krzysztof Hałasa wrote:
> "Russell King (Oracle)" <linux@armlinux.org.uk> 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!

  reply	other threads:[~2021-05-28 14:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26  8:26 Krzysztof Hałasa
2021-05-26 10:08 ` Russell King (Oracle)
2021-05-26 12:29   ` Krzysztof Hałasa
2021-05-26 13:18     ` Russell King (Oracle)
2021-05-27 14:06       ` David Laight
2021-05-28 10:02       ` Krzysztof Hałasa
2021-05-28 14:35         ` Russell King (Oracle) [this message]
2021-05-31  4:30           ` Krzysztof Hałasa
2021-05-31  6:20           ` Krzysztof Hałasa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210528143544.GQ30436@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=khalasa@piap.pl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: Data corruption on i.MX6 IPU in arm_copy_from_user()' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).