linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Brian Norris <computersforpeace@gmail.com>,
	Michal Suchanek <hramrach@gmail.com>
Cc: MTD Maling List <linux-mtd@lists.infradead.org>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	Marek Vasut <marex@denx.de>, Han Xu <han.xu@nxp.com>
Subject: Re: [PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading
Date: Thu, 7 Apr 2016 21:09:56 +0200	[thread overview]
Message-ID: <5706B084.2070909@gmail.com> (raw)
In-Reply-To: <20160405210727.GB5243@localhost>

Am 05.04.2016 um 23:07 schrieb Brian Norris:
> On Tue, Apr 05, 2016 at 10:08:35PM +0200, Heiner Kallweit wrote:
>> Am 05.04.2016 um 21:39 schrieb Brian Norris:
>>> On Sat, Feb 27, 2016 at 11:50:11PM +0100, Heiner Kallweit wrote:
>>>> Some controllers have transfer size limits. To allow to deal with this
>>>> max_transfer_size was introduced in the SPI core recently.
>>>> Use this new feature to read in chunks if needed.
>>>>
>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>>
>>> Michal has been working on a similar series, with some differences (I'll
>>> comment below). I think his latest work is here:
>>>
>>> http://lists.infradead.org/pipermail/linux-mtd/2015-December/063865.html
>>>
>>> Is there a particular reason you've continued on your series instead of
>>> reviewing/fixing his?
>>>
>> Latest version of Michal's patch set was sent beginning of December and has
>> received no comment since then, so I assumed it's dead.
>> If that's not the case, totally fine with me and I'll have a further look at it.
> 
> There was a comment about the loop bounds changing away from page
> alignment. I think otherwise it's about ready to go.
> 
I had a closer look at Michal's patch set, few remarks:

Patch 2 changes the semantics of the return value of m25p80_read/write and the
related change to spi_nor_read/write is part of patch 4.
Means if the first patches are applied only we get a faulty behavior.
Usually this is undesirable, not sure whether it's acceptable here.

Patch 2
+	ret = m.actual_length - cmd_sz;
+	if (ret < 0)
+		return -EIO;
I think we should add special handling for the case ret == 0.
Usually this would indicate an error however there might be
intentional zero-length read's (not sure about that).
Therefore I'd propose to change the error condition to
if (ret < 0 || (!ret && len))
If zero-length reads are not possible we can simply change it to
if (ret <= 0)

Patch 7
W/o the proposed change to patch 2 the case that nor->read()
returns 0 isn't handled correctly.
We'd bail out from the read loop but return 0.
Instead we should return an error in this case.

With the change to patch 2 the case that nor->read() returns 0
can't happen and we should change the error condition to
if (ret < 0) for the sake of clarity.

Patch 8
Made it to mainline already, can be removed.

Patch 10
1. min_t isn't needed here because both arguments are of type size_t.
2. At least in the case of fsl-espi the size limit refers to one
   physical transfer (including the command) and therefore to the sum
   of all transfers.
We should change
+	t[1].len = min_t(size_t, len, spi_max_transfer_size(spi));
to
+	t[1].len = min(len, spi_max_transfer_size(spi) - t[0].len);

Apart from that the patch set looks good to me.

Heiner

> If you or Michal don't take a look at it, I'll rebase and resubmit it.
> 
> Brian
> 

  reply	other threads:[~2016-04-07 19:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-27 22:50 [PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading Heiner Kallweit
2016-04-05 19:39 ` Brian Norris
2016-04-05 20:08   ` Heiner Kallweit
2016-04-05 21:07     ` Brian Norris
2016-04-07 19:09       ` Heiner Kallweit [this message]
2016-05-05 23:57         ` Brian Norris
2016-05-06 12:14           ` Mark Brown
2016-06-03 22:22             ` Heiner Kallweit
2016-06-06 17:40               ` Mark Brown
2016-06-06 18:28                 ` Brian Norris
2016-06-06 18:34                   ` Mark Brown
2016-06-06 18:43                     ` Brian Norris
2016-06-06 18:48                       ` Mark Brown
2016-06-06 18:53                 ` Heiner Kallweit
2016-06-06 19:40                   ` Michal Suchanek
2016-06-06 21:02                     ` Heiner Kallweit
2016-06-06 19:46                   ` Geert Uytterhoeven
2016-06-06 21:20                     ` Heiner Kallweit
2016-06-06 22:28                       ` Marek Vasut
2016-06-07  4:52                         ` Heiner Kallweit
2016-06-06 23:07                   ` Mark Brown
2016-06-07  6:03                     ` Heiner Kallweit
2016-06-07  8:10                       ` Michal Suchanek
2016-06-07 20:42                         ` Heiner Kallweit
2016-06-08 19:51                       ` Heiner Kallweit
2016-06-09  7:12                         ` Michal Suchanek
2016-06-17 20:13                           ` Heiner Kallweit
2016-04-06 13:55   ` Cyrille Pitchen

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=5706B084.2070909@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=han.xu@nxp.com \
    --cc=hramrach@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marex@denx.de \
    /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 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).