linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
	linux-mtd@lists.infradead.org,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>
Subject: RfC: Handle SPI controller limitations like maximum message length
Date: Wed, 18 Nov 2015 22:19:29 +0100	[thread overview]
Message-ID: <564CEB61.2000601@gmail.com> (raw)

There have been few discussions in the past about how to handle SPI controller
limitations like max message length. However they don't seem to have resulted
in accepted patches yet.
I also stumbled across this topic because I own a device using Freescale's
ESPI which has a 64K message size limitation.

At least one agreed fact is that silently assembling chunks in protocol
drivers is not the preferred approach.

Maybe a better approach would be to introduce a new member of spi_master
dealing with controller limitations.
My issue is just the message size limitation but most likely there are more
and different limitations in other controllers.

I'd introduce a struct spi_controller_restrictions and add a member to spi_master
pointing to such a struct. Then a controller driver could do something like this:

static const struct spi_controller_restrictions fsl_espi_restrictions = {
	.max_msg_size	= 0xffff,
};

master->restrictions = &fsl_espi_restrictions;

I also add an example how a protocol driver could use this extension.
Appreciate any comment.


diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 269e8af..8a27c66 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -276,6 +276,17 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
 			spi_unregister_driver)
 
 /**
+ * struct spi_controller_restrictions - restrictions of the controller
+ * @max_msg_size: maximum length of a SPI message
+ * SPI controllers can have different restrictions like a maximum
+ * supported message size.
+ * This struct most likely is going to be extended over time.
+ */
+struct spi_controller_restrictions {
+	size_t max_msg_size;
+};
+
+/**
  * struct spi_master - interface to SPI master controller
  * @dev: device interface to this driver
  * @list: link with the global spi_master list
@@ -295,6 +306,7 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv)
  * @min_speed_hz: Lowest supported transfer speed
  * @max_speed_hz: Highest supported transfer speed
  * @flags: other constraints relevant to this driver
+ * @restrictions: controller restrictions like max supported message size
  * @bus_lock_spinlock: spinlock for SPI bus locking
  * @bus_lock_mutex: mutex for SPI bus locking
  * @bus_lock_flag: indicates that the SPI bus is locked for exclusive use
@@ -417,6 +429,9 @@ struct spi_master {
 #define SPI_MASTER_MUST_RX      BIT(3)		/* requires rx */
 #define SPI_MASTER_MUST_TX      BIT(4)		/* requires tx */
 
+	/* collection of restrictions like max supported message size */
+	struct spi_controller_restrictions *restrictions;
+
 	/* lock and mutex for SPI bus locking */
 	spinlock_t		bus_lock_spinlock;
 	struct mutex		bus_lock_mutex;
-- 
2.6.2




---
 drivers/mtd/devices/m25p80.c | 41 ++++++++++++++++++++++++++++++++++++-----
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index f10daa8..0e46fb1f 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -115,11 +115,7 @@ static inline unsigned int m25p80_rx_nbits(struct spi_nor *nor)
 	}
 }
 
-/*
- * Read an address range from the nor chip.  The address range
- * may be any size provided it is within the physical boundaries.
- */
-static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len,
+static int _m25p80_read(struct spi_nor *nor, loff_t from, size_t len,
 			size_t *retlen, u_char *buf)
 {
 	struct m25p *flash = nor->priv;
@@ -160,6 +156,41 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len,
 	return ret;
 }
 
+/*
+ * Read an address range from the nor chip.  The address range
+ * may be any size provided it is within the physical boundaries.
+ */
+static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len,
+			size_t *retlen, u_char *buf)
+{
+	struct m25p *flash = nor->priv;
+	struct spi_controller_restrictions *restrictions =
+		flash->spi->master->restrictions;
+	size_t cmd_len, xfer_len, max_len;
+	int ret = 0;
+
+	/* convert the dummy cycles to the number of bytes */
+	cmd_len = m25p_cmdsz(nor) + nor->read_dummy / 8;
+
+	max_len = (restrictions && restrictions->max_msg_size) ?
+		  restrictions->max_msg_size : SIZE_MAX;
+
+	if (unlikely(max_len < cmd_len))
+		return -EINVAL;
+
+	max_len -= cmd_len;
+
+	while (len) {
+		xfer_len = min(len, max_len);
+		ret = _m25p80_read(nor, from, xfer_len, retlen, buf);
+		if (ret < 0)
+			break;
+		from += xfer_len;
+		len -= xfer_len;
+	}
+
+	return ret;
+}
+
 static int m25p80_erase(struct spi_nor *nor, loff_t offset)
 {
 	struct m25p *flash = nor->priv;
-- 
2.6.2

             reply	other threads:[~2015-11-18 21:20 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 21:19 Heiner Kallweit [this message]
2015-11-18 21:57 ` RfC: Handle SPI controller limitations like maximum message length Mark Brown
2015-11-18 22:50   ` Heiner Kallweit
2015-11-19 11:40     ` Mark Brown
2015-11-19 15:00       ` Martin Sperl
2015-11-19 17:15         ` Mark Brown
2015-11-20  0:07           ` Brian Norris
2015-11-20 11:06             ` Mark Brown
2015-11-20 11:16               ` Martin Sperl
2015-11-20 10:18           ` Martin Sperl
2015-11-20 12:05             ` Mark Brown
2015-11-20 12:56               ` Martin Sperl
2015-11-21 13:49                 ` Mark Brown
2015-11-21 14:10                   ` Heiner Kallweit
2015-11-21 15:57                     ` Michal Suchanek
2015-11-21 22:59                       ` [PATCH 0/3] spi: mtd: Handle HW message length restrictions Heiner Kallweit
2015-11-21 23:01                       ` [PATCH 1/3] spi: core: add max_msg_size to spi_master Heiner Kallweit
2015-11-22 13:16                         ` Mark Brown
2015-11-22 16:15                           ` Heiner Kallweit
2015-11-23 11:38                             ` Mark Brown
2015-11-27 19:26                               ` Heiner Kallweit
2015-11-30 16:42                                 ` Mark Brown
2015-11-30 20:15                                   ` Heiner Kallweit
2015-11-21 23:08                       ` [PATCH 2/3] mtd: m25p80: handle HW message size restrictions Heiner Kallweit
2015-11-22 12:51                         ` Michal Suchanek
2015-11-21 23:11                       ` [PATCH 3/3] spi: fsl-espi: make use of max_msg_size in spi_master to handle HW restrictions Heiner Kallweit
2015-11-30 20:24                       ` [PATCH v2 1/2] spi: core: add max_msg_size to spi_master Heiner Kallweit
2015-11-30 20:25                       ` [PATCH resubmit 2/2] spi: fsl-espi: make use of max_msg_size in spi_master to handle HW restrictions Heiner Kallweit
2015-12-01 14:19                         ` Mark Brown
2015-12-01 18:53                           ` Heiner Kallweit
2015-11-22 13:19                     ` RfC: Handle SPI controller limitations like maximum message length Mark Brown
2015-11-20  0:02 ` Brian Norris
2015-11-20  6:59   ` Heiner Kallweit
2015-11-20 10:06     ` Heiner Kallweit
2015-11-20 12:35       ` Mark Brown
2015-11-20 18:59         ` Heiner Kallweit
2015-11-20 19:05           ` Michal Suchanek
2015-11-20 19:21             ` Mark Brown
2015-11-20 19:44               ` Michal Suchanek
2015-11-20 23:22             ` Brian Norris
2015-11-21 22:53               ` Heiner Kallweit
2015-11-20 19:18           ` Mark Brown
2015-11-20 19:37             ` Heiner Kallweit
2015-11-20 12:31   ` Mark Brown
2015-11-20 12:56 ` Michal Suchanek
2015-11-20 23:07   ` Brian Norris

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=564CEB61.2000601@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=broonie@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    /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).