From: Pratyush Yadav <p.yadav@ti.com>
To: Michael Walle <michael@walle.cc>
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Mark Brown <broonie@kernel.org>, <linux-mtd@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-spi@vger.kernel.org>
Subject: Re: [PATCH 6/6] mtd: spi-nor: core; avoid odd length/address writes in 8D-8D-8D mode
Date: Fri, 7 May 2021 22:32:00 +0530 [thread overview]
Message-ID: <20210507170158.s76lebxn7v2wyvfy@ti.com> (raw)
In-Reply-To: <497da81bb1531b085941ea2e711cf9b6@walle.cc>
On 07/05/21 05:56PM, Michael Walle wrote:
> Am 2021-05-06 21:18, schrieb Pratyush Yadav:
> > On Octal DTR capable flashes like Micron Xcella the writes cannot start
> > or end at an odd address in Octal DTR mode. Extra 0xff bytes need to be
> > appended or prepended to make sure the start address and end address are
> > even. 0xff is used because on NOR flashes a program operation can only
> > flip bits from 1 to 0, not the other way round. 0 to 1 flip needs to
> > happen via erases.
> >
> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> >
> > ---
> >
> > drivers/mtd/spi-nor/core.c | 72 +++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 71 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > index 3d66cc34af4d..265d8b25fc7f 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> > @@ -2022,6 +2022,71 @@ static int spi_nor_read(struct mtd_info *mtd,
> > loff_t from, size_t len,
> > return ret;
> > }
> >
> > +/*
> > + * On Octal DTR capable flashes like Micron Xcella the writes cannot
> > start or
> > + * end at an odd address in Octal DTR mode. Extra 0xff bytes need to
> > be appended
> > + * or prepended to make sure the start address and end address are
> > even. 0xff is
> > + * used because on NOR flashes a program operation can only flip bits
> > from 1 to
> > + * 0, not the other way round. 0 to 1 flip needs to happen via erases.
> > + */
> > +static int spi_nor_octal_dtr_write(struct spi_nor *nor, loff_t to,
> > size_t len,
> > + const u8 *buf)
> > +{
> > + u8 *tmp_buf;
> > + size_t bytes_written;
> > + loff_t start, end;
> > + int ret;
> > +
> > + if (IS_ALIGNED(to, 2) && IS_ALIGNED(len, 2))
> > + return spi_nor_write_data(nor, to, len, buf);
> > +
> > + tmp_buf = kmalloc(nor->page_size, GFP_KERNEL);
> > + if (!tmp_buf)
> > + return -ENOMEM;
> > +
> > + memset(tmp_buf, 0xff, nor->page_size);
>
> This could be replaced by just setting the first and the
> last byte to 0xff. But this might be easier to read. I am
> fine with both.
First, yes. Not the last. The buffer is allocated to nor->page_size for
simplicity but the write could be smaller than nor->page_size. So you'd
need to calculate the position of the other 0xff byte. It is much
simpler to just initialize the whole buffer. It will be around 256 or
512 bytes so not a big overhead.
>
> > +
> > + start = round_down(to, 2);
> > + end = round_up(to + len, 2);
> > +
> > + memcpy(tmp_buf + (to - start), buf, len);
> > +
> > + ret = spi_nor_write_data(nor, start, end - start, tmp_buf);
> > + if (ret == 0) {
> > + ret = -EIO;
> > + goto out;
> > + }
> else if ? I've missed this in the other patch.
Following the style used in spi_nor_read(). Anyway, I've seen
conflicting advice on which style to be used. Some people don't like
else if when the if ends in a return since it is effectively an else if.
Others like it the other way round. Dunno...
>
> > + if (ret < 0)
> > + goto out;
> > +
> > + /*
> > + * More bytes are written than actually requested, but that number
> > can't
> > + * be reported to the calling function or it will confuse its
> > + * calculations. Calculate how many of the _requested_ bytes were
> > + * written.
> > + */
> > + bytes_written = ret;
> > +
> > + if (to != start)
> > + ret -= to - start;
> > +
> > + /*
> > + * Only account for extra bytes at the end if they were actually
> > + * written. For example, if for some reason the controller could only
> > + * complete a partial write then the adjustment for the extra bytes at
> > + * the end is not needed.
> > + */
> > + if (start + bytes_written == end)
> > + ret -= end - (to + len);
> > +
> > + if (ret < 0)
> > + ret = -EIO;
>
> can this happen?
I don't think so. IIRC this is left over from when I tried a different
approach. Maybe I should change it to WARN_ON() to catch future
programming errors? Though I don't mind if we drop it entirely.
>
> > +
> > +out:
> > + kfree(tmp_buf);
> > + return ret;
> > +}
> > +
> > /*
> > * Write an address range to the nor chip. Data must be written in
> > * FLASH_PAGESIZE chunks. The address range may be any size provided
> > @@ -2066,7 +2131,12 @@ static int spi_nor_write(struct mtd_info *mtd,
> > loff_t to, size_t len,
> > if (ret)
> > goto write_err;
> >
> > - ret = spi_nor_write_data(nor, addr, page_remain, buf + i);
> > + if (nor->write_proto == SNOR_PROTO_8_8_8_DTR)
> > + ret = spi_nor_octal_dtr_write(nor, addr, page_remain,
> > + buf + i);
> > + else
> > + ret = spi_nor_write_data(nor, addr, page_remain,
> > + buf + i);
> > if (ret < 0)
> > goto write_err;
> > written = ret;
>
> -michael
Thanks for reviewing.
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
next prev parent reply other threads:[~2021-05-07 17:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-06 19:18 [PATCH 0/6] Avoid odd length/address read/writes in 8D-8D-8D mode Pratyush Yadav
2021-05-06 19:18 ` [PATCH 1/6] mtd: spi-nor: core: use 2 data bytes for template ops Pratyush Yadav
2021-05-06 19:18 ` [PATCH 2/6] mtd: spi-nor: spansion: write 2 bytes when disabling Octal DTR mode Pratyush Yadav
2021-05-06 19:18 ` [PATCH 3/6] mtd: spi-nor: micron-st: " Pratyush Yadav
2021-05-06 19:18 ` [PATCH 4/6] spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode Pratyush Yadav
2021-05-07 12:55 ` Mark Brown
2021-05-07 13:56 ` Pratyush Yadav
2021-05-07 15:31 ` Mark Brown
2021-05-07 15:48 ` Mark Brown
2021-05-07 16:49 ` Pratyush Yadav
2021-05-06 19:18 ` [PATCH 5/6] mtd: spi-nor: core; avoid odd length/address reads on " Pratyush Yadav
2021-05-07 15:51 ` Michael Walle
2021-05-07 18:04 ` Pratyush Yadav
2021-05-07 18:14 ` Michael Walle
2021-05-07 18:23 ` Pratyush Yadav
2021-05-06 19:18 ` [PATCH 6/6] mtd: spi-nor: core; avoid odd length/address writes in " Pratyush Yadav
2021-05-07 15:56 ` Michael Walle
2021-05-07 17:02 ` Pratyush Yadav [this message]
2021-05-07 15:50 ` [PATCH 0/6] Avoid odd length/address read/writes " Mark Brown
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=20210507170158.s76lebxn7v2wyvfy@ti.com \
--to=p.yadav@ti.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=tudor.ambarus@microchip.com \
--cc=vigneshr@ti.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;
as well as URLs for NNTP newsgroup(s).