All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <p.yadav@ti.com>
To: Tudor Ambarus <tudor.ambarus@microchip.com>,
	Michael Walle <michael@walle.cc>,
	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>
Cc: Pratyush Yadav <p.yadav@ti.com>
Subject: [PATCH 0/6] Avoid odd length/address read/writes in 8D-8D-8D mode.
Date: Fri, 7 May 2021 00:48:23 +0530	[thread overview]
Message-ID: <20210506191829.8271-1-p.yadav@ti.com> (raw)

Hi,

On Octal DTR flashes like Micron Xcella or Cypress S28 family, reads or
writes cannot start at an odd address in 8D-8D-8D mode. Neither can they
be odd bytes long. Upper layers like filesystems don't know what mode
the flash is in, and hence don't know the read/write address or length
limitations. They might issue reads or writes that leave the flash in an
error state. In fact, using UBIFS on top of the flash was how I first
noticed this problem.

This series fixes that problem by padding the read/write with extra
bytes to make sure the final operation has an even address and length.
More info in patches 5 and 6.

Patches 1-3 fix some existing odd-byte long reads. Patch 4 adds checks
to disallow odd length command/address/dummy/data phases in 8D-8D-8D
mode. Note that this does not restrict the _value_ of the address from
being odd since this is a restriction on the flash, not the protocol
itself.

Patch 4 should go through the SPI tree but I have included it in this
series because if it goes in before patches 1-3, Micron MT35XU and
Cypress S28HS flashes will stop working correctly.

Tested on TI J721E for Micron MT35 and on TI J7200 for Cypress S28.


Pratyush Yadav (6):
  mtd: spi-nor: core: use 2 data bytes for template ops
  mtd: spi-nor: spansion: write 2 bytes when disabling Octal DTR mode
  mtd: spi-nor: micron-st: write 2 bytes when disabling Octal DTR mode
  spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode
  mtd: spi-nor: core; avoid odd length/address reads on 8D-8D-8D mode
  mtd: spi-nor: core; avoid odd length/address writes in 8D-8D-8D mode

 drivers/mtd/spi-nor/core.c      | 157 +++++++++++++++++++++++++++++++-
 drivers/mtd/spi-nor/micron-st.c |  22 ++++-
 drivers/mtd/spi-nor/spansion.c  |  18 +++-
 drivers/spi/spi-mem.c           |  12 ++-
 4 files changed, 194 insertions(+), 15 deletions(-)

-- 
2.30.0


WARNING: multiple messages have this Message-ID (diff)
From: Pratyush Yadav <p.yadav@ti.com>
To: Tudor Ambarus <tudor.ambarus@microchip.com>,
	Michael Walle <michael@walle.cc>,
	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>
Cc: Pratyush Yadav <p.yadav@ti.com>
Subject: [PATCH 0/6] Avoid odd length/address read/writes in 8D-8D-8D mode.
Date: Fri, 7 May 2021 00:48:23 +0530	[thread overview]
Message-ID: <20210506191829.8271-1-p.yadav@ti.com> (raw)

Hi,

On Octal DTR flashes like Micron Xcella or Cypress S28 family, reads or
writes cannot start at an odd address in 8D-8D-8D mode. Neither can they
be odd bytes long. Upper layers like filesystems don't know what mode
the flash is in, and hence don't know the read/write address or length
limitations. They might issue reads or writes that leave the flash in an
error state. In fact, using UBIFS on top of the flash was how I first
noticed this problem.

This series fixes that problem by padding the read/write with extra
bytes to make sure the final operation has an even address and length.
More info in patches 5 and 6.

Patches 1-3 fix some existing odd-byte long reads. Patch 4 adds checks
to disallow odd length command/address/dummy/data phases in 8D-8D-8D
mode. Note that this does not restrict the _value_ of the address from
being odd since this is a restriction on the flash, not the protocol
itself.

Patch 4 should go through the SPI tree but I have included it in this
series because if it goes in before patches 1-3, Micron MT35XU and
Cypress S28HS flashes will stop working correctly.

Tested on TI J721E for Micron MT35 and on TI J7200 for Cypress S28.


Pratyush Yadav (6):
  mtd: spi-nor: core: use 2 data bytes for template ops
  mtd: spi-nor: spansion: write 2 bytes when disabling Octal DTR mode
  mtd: spi-nor: micron-st: write 2 bytes when disabling Octal DTR mode
  spi: spi-mem: reject partial cycle transfers in 8D-8D-8D mode
  mtd: spi-nor: core; avoid odd length/address reads on 8D-8D-8D mode
  mtd: spi-nor: core; avoid odd length/address writes in 8D-8D-8D mode

 drivers/mtd/spi-nor/core.c      | 157 +++++++++++++++++++++++++++++++-
 drivers/mtd/spi-nor/micron-st.c |  22 ++++-
 drivers/mtd/spi-nor/spansion.c  |  18 +++-
 drivers/spi/spi-mem.c           |  12 ++-
 4 files changed, 194 insertions(+), 15 deletions(-)

-- 
2.30.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

             reply	other threads:[~2021-05-06 19:18 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 19:18 Pratyush Yadav [this message]
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   ` 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   ` Pratyush Yadav
2021-05-06 19:18 ` [PATCH 3/6] mtd: spi-nor: micron-st: " Pratyush Yadav
2021-05-06 19:18   ` 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-06 19:18   ` Pratyush Yadav
2021-05-07 12:55   ` Mark Brown
2021-05-07 12:55     ` Mark Brown
2021-05-07 13:56     ` Pratyush Yadav
2021-05-07 13:56       ` Pratyush Yadav
2021-05-07 15:31       ` Mark Brown
2021-05-07 15:31         ` Mark Brown
2021-05-07 15:48   ` Mark Brown
2021-05-07 15:48     ` Mark Brown
2021-05-07 16:49     ` Pratyush Yadav
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-06 19:18   ` Pratyush Yadav
2021-05-07 15:51   ` Michael Walle
2021-05-07 15:51     ` Michael Walle
2021-05-07 18:04     ` Pratyush Yadav
2021-05-07 18:04       ` Pratyush Yadav
2021-05-07 18:14       ` Michael Walle
2021-05-07 18:14         ` Michael Walle
2021-05-07 18:23         ` Pratyush Yadav
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-06 19:18   ` Pratyush Yadav
2021-05-07 15:56   ` Michael Walle
2021-05-07 15:56     ` Michael Walle
2021-05-07 17:02     ` Pratyush Yadav
2021-05-07 17:02       ` Pratyush Yadav
2021-05-07 15:50 ` [PATCH 0/6] Avoid odd length/address read/writes " Mark Brown
2021-05-07 15:50   ` 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=20210506191829.8271-1-p.yadav@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 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.