All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hiep Cao Minh <cm-hiep@jinso.co.jp>
To: Geert Uytterhoeven <geert@linux-m68k.org>, DongCV <cv-dong@jinso.co.jp>
Cc: "Mark Brown" <broonie@kernel.org>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	linux-spi <linux-spi@vger.kernel.org>,
	"Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
	"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
	"Ryusuke Sakato" <ryusuke.sakato.bx@renesas.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Dung:人ソ <nv-dung@jinso.co.jp>, 稲吉 <h-inayoshi@jinso.co.jp>
Subject: Re: [PATCH] spi: rspi: fix the bug related to mount/remount jffs2
Date: Mon, 13 Feb 2017 15:50:12 +0900	[thread overview]
Message-ID: <58A15724.1060901@jinso.co.jp> (raw)
In-Reply-To: <CAMuHMdVDgjBF+c-z4=LH+PD00oiNFqhShQuZ0ELS0S4YpQ=npg@mail.gmail.com>

Hi Geert,

Sorry to bother you!
> qspi_transfer_in() does:
>
>          while (n > 0) {
>                  len = qspi_set_receive_trigger(rspi, n);
>                  // len will be <= n
I agree. This is len = min value of n and 32.
>                  if (len == QSPI_BUFFER_SIZE) {
>                          // receive blocks of len bytes
Yes, This is len == 32 bytes
>                          ...
>                  } else {
>                          // receive n (not len) bytes
This is always n == len ( This case, len or n is always < 32)
Because this is the last n bytes should be received.

>                          ret = rspi_pio_transfer(rspi, NULL, rx, n);
>                          //
>                          if (ret < 0)
>                                  return ret;
>                          // bogus write (which your patch removes: OK)
>                          *rx++ = ret;
I agree. This code needs to be removed.

>                          // here we should also return (see below why)
>                          // (in qspi_transfer_out() we should "break")
>                  }
>                  // Either we received a block of len bytes
>                  // or we received n bytes, and the below is wrong if len < n!
>                  n -= len;
>                  // If len was < n, n will be non-zero, and we will receive more
>                  // bytes in the next iteration
I am sorry, I don't understand your opinion here also.
The following is my opinion:

In case of receiving n bytes data > 32 bytes (Ex: n= 50bytes)
The first loop, n= 50,and  len = 32 bytes by getting min value of 50 and 
32 from qspi_set_receive_trigger()
(this case was n < len).
Then it receives 32 bytes in "if (len == QSPI_BUFFER_SIZE)" statement.
After received 32bytes of data, n -= len is implemented. It means n =(n 
- len) = (50-32)= 18 bytes.
The first loop finished.

The second loop, n=18 bytes, and len = 18 bytes by getting min value of 
32 and 18 from qspi_set_receive_trigger().
This time, 'else' statement would be implemented. *rx pointer was 
increased into rspi_pio_transfer()
After received the last 18 bytes of data into 'else' statement, n -=len 
was implemented again.
It means n = (n - len) = (18 -18) = 0 byte.
The second loop finished.

This time n = 0, Completed receiving data.

In case of receiving n bytes data < 32 bytes  (Ex: n= 20 bytes).
It's the same with the second loop above.

Thank you.
Hiep.

  reply	other threads:[~2017-02-13  6:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-06  1:02 [PATCH] spi: rspi: fix the bug related to mount/remount jffs2 DongCV
2017-02-06  1:02 ` DongCV
2017-02-06 11:02 ` Geert Uytterhoeven
2017-02-07 10:25   ` DongCV
2017-02-08  8:58     ` Geert Uytterhoeven
2017-02-08  8:58       ` Geert Uytterhoeven
2017-02-13  6:50       ` Hiep Cao Minh [this message]
2017-02-13  8:07         ` Geert Uytterhoeven
2017-02-13  8:07           ` Geert Uytterhoeven
2017-02-15  0:26           ` Hiep Cao Minh
2017-02-06 12:46 ` Mark Brown
2017-02-13  8:26   ` Geert Uytterhoeven
2017-02-16 19:05 ` Applied "spi: rspi: Fixes bogus received byte in qspi_transfer_in()" to the spi tree Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2017-01-27  8:12 [PATCH] spi: rspi: fix the bug related to mount/remount jffs2 DongCV
     [not found] ` <74ea1835-3ce3-612c-ece5-52c8dba0ca87-HEF513clHfp3+QwDJ9on6Q@public.gmane.org>
2017-01-27  9:00   ` Geert Uytterhoeven
2017-01-27  9:02     ` Geert Uytterhoeven
2017-01-27  9:02       ` Geert Uytterhoeven
     [not found]     ` <CAMuHMdVZOOLGziGm4YdHn_bRB_JOzWEeQ=Ogr8TiB47KTza7OA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-01  7:08       ` DongCV

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=58A15724.1060901@jinso.co.jp \
    --to=cm-hiep@jinso.co.jp \
    --cc=broonie@kernel.org \
    --cc=cv-dong@jinso.co.jp \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=h-inayoshi@jinso.co.jp \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=nv-dung@jinso.co.jp \
    --cc=ryusuke.sakato.bx@renesas.com \
    --cc=yoshihiro.shimoda.uh@renesas.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.