All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Gabbasov <andrew_gabbasov@mentor.com>
To: 'Krzysztof Kozlowski' <krzysztof.kozlowski@canonical.com>,
	<linux-renesas-soc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Sergei Shtylyov <sergei.shtylyov@gmail.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>
Subject: RE: [PATCH] memory: renesas-rpc-if: Avoid unaligned bus access for HyperFlash
Date: Fri, 24 Sep 2021 15:34:42 +0300	[thread overview]
Message-ID: <000001d7b140$91e0a180$b5a1e480$@mentor.com> (raw)
In-Reply-To: <c6de6ec0-fd06-14bc-c483-52a2d0a4590a@canonical.com>

Hello Krzysztof,

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Sent: Friday, September 24, 2021 2:13 PM
> To: Gabbasov, Andrew <Andrew_Gabbasov@mentor.com>; linux-renesas-soc@vger.kernel.org; linux-
> kernel@vger.kernel.org; Sergei Shtylyov <sergei.shtylyov@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>
> Subject: Re: [PATCH] memory: renesas-rpc-if: Avoid unaligned bus access for HyperFlash
> 
> On 22/09/2021 20:48, Andrew Gabbasov wrote:
> > HyperFlash devices in Renesas SoCs use 2-bytes addressing, according
> > to HW manual paragraph 62.3.3 (which officially describes Serial Flash
> > access, but seems to be applicable to HyperFlash too). And 1-byte bus
> > read operations to 2-bytes unaligned addresses in external address space
> > read mode work incorrectly (returns the other byte from the same word).
> >
> > Function memcpy_fromio(), used by the driver to read data from the bus,
> > in ARM64 architecture (to which Renesas cores belong) uses 8-bytes
> > bus accesses for appropriate aligned addresses, and 1-bytes accesses
> > for other addresses. This results in incorrect data read from HyperFlash
> > in unaligned cases.
> >
> > This issue can be reproduced using something like the following commands
> > (where mtd1 is a parition on Hyperflash storage, defined properly
> > in a device tree):
> >
> > [Correct fragment, read from Hyperflash]
> >
> >     root@rcar-gen3:~# dd if=/dev/mtd1 of=/tmp/zz bs=32 count=1
> >     1+0 records in
> >     1+0 records out
> >     root@rcar-gen3:~# hexdump -C /tmp/zz
> >     00000000  f4 03 00 aa f5 03 01 aa  f6 03 02 aa f7 03 03 aa  |................|
> >     00000010  00 00 80 d2 40 20 18 d5  00 06 81 d2 a0 18 a6 f2  |....@ ..........|
> >     00000020
> >
> > [Incorrect read of the same fragment: see the difference at offsets 8-11]
> >
> >     root@rcar-gen3:~# dd if=/dev/mtd1 of=/tmp/zz bs=12 count=1
> >     1+0 records in
> >     1+0 records out
> >     root@rcar-gen3:~# hexdump -C /tmp/zz
> >     00000000  f4 03 00 aa f5 03 01 aa  03 03 aa aa              |............|
> >     0000000c
> >
> > Fix this issue by creating a local replacement of the copying function,
> > that performs only properly aligned bus accesses, and is used for reading
> > from HyperFlash.
> >
> > Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
> > Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
> > ---
> >  drivers/memory/renesas-rpc-if.c | 47 ++++++++++++++++++++++++++++++++-
> >  1 file changed, 46 insertions(+), 1 deletion(-)
> >
> 
> Thanks for the patch.
> 
> Please rebase and test on a recent Linux kernel. This looks like work on
> something slightly older or stable kernel, since you Cc not the address
> from maintainers.

The patch is already against the recent kernel versions.
Sorry for using wrong address, I have probably taken it from some
older mailing lists.

> The patch came slightly after Wolfram's and I wonder whether you hit
> similar issue:
> https://lore.kernel.org/lkml/20210922091007.5516-1-wsa+renesas@sang-engineering.com/

If I correctly understand, the underlying issue looks similar (improperly aligned
memory/register accesses), but the affected areas are different, even non-intersecting:
Wolfram fixes register access, affecting manual mode reads/writes, having problems
with QSPI devices, while my fix is related to external address space reads (mapped
memory access) with Hyperflash devices.

Thanks.

Best regards,
Andrew


  reply	other threads:[~2021-09-24 12:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 18:48 [PATCH] memory: renesas-rpc-if: Avoid unaligned bus access for HyperFlash Andrew Gabbasov
2021-09-24 11:12 ` Krzysztof Kozlowski
2021-09-24 12:34   ` Andrew Gabbasov [this message]
2021-09-24 12:37     ` Wolfram Sang
2021-09-25  9:54 ` Wolfram Sang
2021-09-25 10:49   ` Andrew Gabbasov
2021-09-27  9:25     ` 'Wolfram Sang'
2021-09-28 10:35 ` Krzysztof Kozlowski

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='000001d7b140$91e0a180$b5a1e480$@mentor.com' \
    --to=andrew_gabbasov@mentor.com \
    --cc=geert+renesas@glider.be \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=sergei.shtylyov@gmail.com \
    --cc=wsa+renesas@sang-engineering.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.