linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>,
	Pratyush Yadav <p.yadav@ti.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Michael Walle <michael@walle.cc>
Subject: [RFC PATCH 1/3] mtd: spi-nor: support dumping sfdp tables
Date: Fri, 12 Mar 2021 20:05:45 +0100	[thread overview]
Message-ID: <20210312190548.6954-1-michael@walle.cc> (raw)

Add the possibility to dump the SFDP data of a flash device.

More and more flash devices share the same flash ID and we need per device
fixups. Usually, these fixups differentiate flashes by looking at
differences in the SFDP data. Determining the difference is only possible
if we have the SFDP data for all the flashes which share a flash ID. This
will lay the foundation to dump the whole SFDP data of a flash device.

This is even more important, because some datasheets doesn't even contain
the SFDP data. Fixups for these kind of flashes are nearly impossible to
do.

I envision having a database of all the SFDP data for the flashes we
support and make it a requirement to submit it when a new flash is added.
This might or might not have legal implications. Thus I'd start with having
that database private to the SPI NOR maintainers.

There are two ways to provide access to the SFDP data:
 (1) We just read the SFDP data once and cache it
 (2) Any userspace access will always read the SFDP data

I choose (2) because it isn't as invasive as (1). The current SFDP code
reads the SFDP data only partially and only the part which are actually
used. Using (1) would mean to change that behavior.

Michael Walle (3):
  mtd: spi-nor: sfdp: remember sfdp_size
  mtd: spi-nor: sfdp: fix spi_nor_read_sfdp()
  mtd: spi-nor: add sysfs and SFDP support

 drivers/mtd/spi-nor/Makefile |  2 +-
 drivers/mtd/spi-nor/core.c   |  5 +++
 drivers/mtd/spi-nor/core.h   |  3 ++
 drivers/mtd/spi-nor/sfdp.c   | 24 +++++++++++-
 drivers/mtd/spi-nor/sfdp.h   |  2 +
 drivers/mtd/spi-nor/sysfs.c  | 73 ++++++++++++++++++++++++++++++++++++
 include/linux/mtd/spi-nor.h  |  1 +
 7 files changed, 107 insertions(+), 3 deletions(-)
 create mode 100644 drivers/mtd/spi-nor/sysfs.c

-- 
2.20.1


             reply	other threads:[~2021-03-12 19:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 19:05 Michael Walle [this message]
2021-03-12 19:05 ` [RFC PATCH 1/3] mtd: spi-nor: sfdp: remember sfdp_size Michael Walle
2021-03-16 10:42   ` Pratyush Yadav
2021-03-16 11:01     ` Michael Walle
2021-03-16 11:06       ` Pratyush Yadav
2021-03-16 11:22         ` Michael Walle
2021-03-12 19:05 ` [RFC PATCH 2/3] mtd: spi-nor: sfdp: fix spi_nor_read_sfdp() Michael Walle
2021-03-16 11:04   ` Pratyush Yadav
2021-03-16 11:15     ` Michael Walle
2021-03-16 13:15       ` Pratyush Yadav
2021-03-12 19:05 ` [RFC PATCH 3/3] mtd: spi-nor: add sysfs and SFDP support Michael Walle

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=20210312190548.6954-1-michael@walle.cc \
    --to=michael@walle.cc \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.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).