From: Marek Vasut <marex@denx.de>
To: Michal Suchanek <hramrach@gmail.com>
Cc: "David Woodhouse" <dwmw2@infradead.org>,
"Brian Norris" <computersforpeace@gmail.com>,
"Han Xu" <han.xu@freescale.com>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Alison Chaiken" <alison_chaiken@mentor.com>,
"Huang Shijie" <b32955@freescale.com>,
"Ben Hutchings" <ben@decadent.org.uk>,
"Gabor Juhos" <juhosg@openwrt.org>,
"Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>,
"MTD Maling List" <linux-mtd@lists.infradead.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mtd: spi-nor: rework spi nor read and write.
Date: Wed, 29 Jul 2015 19:03:35 +0200 [thread overview]
Message-ID: <201507291903.36020.marex@denx.de> (raw)
In-Reply-To: <CAOMqctRvoX9w9euyPqD_aBrz=d_pCC9AYKCg2HVrZ-tLOcAibQ@mail.gmail.com>
On Wednesday, July 29, 2015 at 06:16:21 AM, Michal Suchanek wrote:
> On 28 July 2015 at 20:15, Marek Vasut <marex@denx.de> wrote:
> > On Tuesday, July 28, 2015 at 11:23:02 AM, Michal Suchanek wrote:
> >> The spi_nor read and write functions pass thru the mtd retlen to the
> >> chip-specific read and write function. This makes it difficult to check
> >> for errors in read and write functions and these errors are not checked.
> >> This leads to silent data corruption.
> >>
> >> This patch styles the chip-specific read and write function as unix
> >> read(2) and write(2) and updates the retlen in the spi-nor generic
> >> driver.
> >>
> >> This also makes it possible to check for write errors.
> >> When pl330 fails to transfer the flash data over SPI I get I/O error
> >> instead of 4M of zeroes.
> >>
> >> I do not have sst and fsl hardware to test with.
> >>
> >> Signed-off-by: Michal Suchanek <hramrach@gmail.com>
> >> ---
> >>
> >> drivers/mtd/devices/m25p80.c | 33 ++++++++++++++---------
> >> drivers/mtd/spi-nor/fsl-quadspi.c | 29 ++++++++++----------
> >> drivers/mtd/spi-nor/spi-nor.c | 57
> >>
> >> ++++++++++++++++++++++++++++----------- include/linux/mtd/spi-nor.h
> >>
> >> | 8 +++---
> >>
> >> 4 files changed, 81 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> >> index d313f948b..d8f064b 100644
> >> --- a/drivers/mtd/devices/m25p80.c
> >> +++ b/drivers/mtd/devices/m25p80.c
> >> @@ -75,14 +75,15 @@ static int m25p80_write_reg(struct spi_nor *nor, u8
> >> opcode, u8 *buf, int len, return spi_write(spi, flash->command, len +
> >> 1);
> >>
> >> }
> >>
> >> -static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
> >> - size_t *retlen, const u_char *buf)
> >> +static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
> >> + const u_char *buf)
> >>
> >> {
> >>
> >> struct m25p *flash = nor->priv;
> >> struct spi_device *spi = flash->spi;
> >> struct spi_transfer t[2] = {};
> >> struct spi_message m;
> >> int cmd_sz = m25p_cmdsz(nor);
> >>
> >> + ssize_t ret;
> >>
> >> spi_message_init(&m);
> >>
> >> @@ -100,9 +101,14 @@ static void m25p80_write(struct spi_nor *nor,
> >> loff_t to, size_t len, t[1].len = len;
> >>
> >> spi_message_add_tail(&t[1], &m);
> >>
> >> - spi_sync(spi, &m);
> >> + ret = spi_sync(spi, &m);
> >> + if (ret)
> >> + return ret;
> >>
> >> - *retlen += m.actual_length - cmd_sz;
> >> + ret = m.actual_length - cmd_sz;
> >> + if (ret < 0)
> >> + return -EIO;
> >> + return ret;
> >
> > I'd prefer to just add the return value and keep the retlen to keep error
> > codes and transfer length separate.
>
> I prefer to not pass around retlen because passing it around
>
> - causes code duplication
> - makes the code harder to understand
Not sure I want to argue on this one, since it looks like a matter of taste.
Adding the error return first and removing the retlen second might make the
patch more readable though.
> > btw. you change the transfer length from unsigned to signed type -- long
> > transfer might get interpreted as an error.
>
> Note that ssize_t is supposed to be enough for write(2) so when it
> does not suffice you have a real system-wide problem.
>
> That aside NOR flash sizes tend to be in the order of megabytes so
> this concern is very theoretical.
I do hope so :)
prev parent reply other threads:[~2015-07-29 17:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1438074682.git.hramrach@gmail.com>
[not found] ` <79b4c3521cdb13872c7cf939ea25219399c1a345.1438074682.git.hramrach@gmail.com>
2015-07-28 18:15 ` [PATCH 1/2] mtd: spi-nor: rework spi nor read and write Marek Vasut
2015-07-29 4:16 ` Michal Suchanek
2015-07-29 17:03 ` Marek Vasut [this message]
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=201507291903.36020.marex@denx.de \
--to=marex@denx.de \
--cc=alison_chaiken@mentor.com \
--cc=b32955@freescale.com \
--cc=beanhuo@micron.com \
--cc=ben@decadent.org.uk \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=han.xu@freescale.com \
--cc=hramrach@gmail.com \
--cc=juhosg@openwrt.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=zajec5@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox