All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-15 15:23 ` Jonatas Rech
  0 siblings, 0 replies; 13+ messages in thread
From: Jonatas Rech @ 2015-04-15 15:23 UTC (permalink / raw)
  To: broonie; +Cc: linux-spi, linux-kernel, Jonatas Rech

This patch makes possible for protocol drivers to do full-duplex SPI
transfers properly. Until now this driver could only be used for
half-duplex transfers, since it always expected an spi_transfer with
non-null tx_buf to be only used for TX, and those with non-null rx_buf
to be only used for RX.

The fix consists in correcting the fsl_espi_transfer length by taking
into consideration duplex spi_transfers, and not just by adding n_tx
and n_rx.

Furthermore, this correction has exposed an inconsistency in the
protocol driver <-> controller driver interaction. The spi-fsl-espi
driver artificially inserts TX bytes when message fragmentation is
necessary (due to SPCOM_TRANLEN_MAX) instead of informing the
protocol driver of the hardware limitation. This was tested with the
m25p80 NOR flash protocol driver. Since fixing this issue may cause
other client drivers to malfunction, it was left as is.

Signed-off-by: Jonatas Rech <jonatas.rech@datacom.ind.br>
---
 drivers/spi/spi-fsl-espi.c | 45 +++++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index d0a73a0..80d245a 100644
--- a/drivers/spi/spi-fsl-espi.c
+++ b/drivers/spi/spi-fsl-espi.c
@@ -359,14 +359,16 @@ static void fsl_espi_rw_trans(struct spi_message *m,
 				struct fsl_espi_transfer *trans, u8 *rx_buff)
 {
 	struct fsl_espi_transfer *espi_trans = trans;
-	unsigned int n_tx = espi_trans->n_tx;
-	unsigned int n_rx = espi_trans->n_rx;
+	unsigned int total_len = espi_trans->len;
 	struct spi_transfer *t;
 	u8 *local_buf;
 	u8 *rx_buf = rx_buff;
 	unsigned int trans_len;
 	unsigned int addr;
-	int i, pos, loop;
+	unsigned int tx_only;
+	unsigned int rx_pos = 0;
+	unsigned int pos;
+	int i, loop;
 
 	local_buf = kzalloc(SPCOM_TRANLEN_MAX, GFP_KERNEL);
 	if (!local_buf) {
@@ -374,36 +376,48 @@ static void fsl_espi_rw_trans(struct spi_message *m,
 		return;
 	}
 
-	for (pos = 0, loop = 0; pos < n_rx; pos += trans_len, loop++) {
-		trans_len = n_rx - pos;
-		if (trans_len > SPCOM_TRANLEN_MAX - n_tx)
-			trans_len = SPCOM_TRANLEN_MAX - n_tx;
+	for (pos = 0, loop = 0; pos < total_len; pos += trans_len, loop++) {
+		trans_len = total_len - pos;
 
 		i = 0;
+		tx_only = 0;
 		list_for_each_entry(t, &m->transfers, transfer_list) {
 			if (t->tx_buf) {
 				memcpy(local_buf + i, t->tx_buf, t->len);
 				i += t->len;
+				if (!t->rx_buf)
+					tx_only += t->len;
 			}
 		}
 
+		/* Add additional TX bytes to compensate SPCOM_TRANLEN_MAX */
+		if (loop > 0)
+			trans_len += tx_only;
+
+		if (trans_len > SPCOM_TRANLEN_MAX)
+			trans_len = SPCOM_TRANLEN_MAX;
+
+		/* Update device offset */
 		if (pos > 0) {
 			addr = fsl_espi_cmd2addr(local_buf);
-			addr += pos;
+			addr += rx_pos;
 			fsl_espi_addr2cmd(addr, local_buf);
 		}
 
-		espi_trans->n_tx = n_tx;
-		espi_trans->n_rx = trans_len;
-		espi_trans->len = trans_len + n_tx;
+		espi_trans->len = trans_len;
 		espi_trans->tx_buf = local_buf;
 		espi_trans->rx_buf = local_buf;
 		fsl_espi_do_trans(m, espi_trans);
 
-		memcpy(rx_buf + pos, espi_trans->rx_buf + n_tx, trans_len);
+		/* If there is at least one RX byte then copy it to rx_buf */
+		if (tx_only < SPCOM_TRANLEN_MAX)
+			memcpy(rx_buf + rx_pos, espi_trans->rx_buf + tx_only,
+					trans_len - tx_only);
+
+		rx_pos += trans_len - tx_only;
 
 		if (loop > 0)
-			espi_trans->actual_length += espi_trans->len - n_tx;
+			espi_trans->actual_length += espi_trans->len - tx_only;
 		else
 			espi_trans->actual_length += espi_trans->len;
 	}
@@ -418,6 +432,7 @@ static int fsl_espi_do_one_msg(struct spi_master *master,
 	u8 *rx_buf = NULL;
 	unsigned int n_tx = 0;
 	unsigned int n_rx = 0;
+	unsigned int xfer_len = 0;
 	struct fsl_espi_transfer espi_trans;
 
 	list_for_each_entry(t, &m->transfers, transfer_list) {
@@ -427,11 +442,13 @@ static int fsl_espi_do_one_msg(struct spi_master *master,
 			n_rx += t->len;
 			rx_buf = t->rx_buf;
 		}
+		if ((t->tx_buf) || (t->rx_buf))
+			xfer_len += t->len;
 	}
 
 	espi_trans.n_tx = n_tx;
 	espi_trans.n_rx = n_rx;
-	espi_trans.len = n_tx + n_rx;
+	espi_trans.len = xfer_len;
 	espi_trans.actual_length = 0;
 	espi_trans.status = 0;
 
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-15 15:23 ` Jonatas Rech
  0 siblings, 0 replies; 13+ messages in thread
From: Jonatas Rech @ 2015-04-15 15:23 UTC (permalink / raw)
  To: broonie-DgEjT+Ai2ygdnm+yROfE0A
  Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jonatas Rech

This patch makes possible for protocol drivers to do full-duplex SPI
transfers properly. Until now this driver could only be used for
half-duplex transfers, since it always expected an spi_transfer with
non-null tx_buf to be only used for TX, and those with non-null rx_buf
to be only used for RX.

The fix consists in correcting the fsl_espi_transfer length by taking
into consideration duplex spi_transfers, and not just by adding n_tx
and n_rx.

Furthermore, this correction has exposed an inconsistency in the
protocol driver <-> controller driver interaction. The spi-fsl-espi
driver artificially inserts TX bytes when message fragmentation is
necessary (due to SPCOM_TRANLEN_MAX) instead of informing the
protocol driver of the hardware limitation. This was tested with the
m25p80 NOR flash protocol driver. Since fixing this issue may cause
other client drivers to malfunction, it was left as is.

Signed-off-by: Jonatas Rech <jonatas.rech-rCUF4CxDseZknzVnJbg3IA@public.gmane.org>
---
 drivers/spi/spi-fsl-espi.c | 45 +++++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index d0a73a0..80d245a 100644
--- a/drivers/spi/spi-fsl-espi.c
+++ b/drivers/spi/spi-fsl-espi.c
@@ -359,14 +359,16 @@ static void fsl_espi_rw_trans(struct spi_message *m,
 				struct fsl_espi_transfer *trans, u8 *rx_buff)
 {
 	struct fsl_espi_transfer *espi_trans = trans;
-	unsigned int n_tx = espi_trans->n_tx;
-	unsigned int n_rx = espi_trans->n_rx;
+	unsigned int total_len = espi_trans->len;
 	struct spi_transfer *t;
 	u8 *local_buf;
 	u8 *rx_buf = rx_buff;
 	unsigned int trans_len;
 	unsigned int addr;
-	int i, pos, loop;
+	unsigned int tx_only;
+	unsigned int rx_pos = 0;
+	unsigned int pos;
+	int i, loop;
 
 	local_buf = kzalloc(SPCOM_TRANLEN_MAX, GFP_KERNEL);
 	if (!local_buf) {
@@ -374,36 +376,48 @@ static void fsl_espi_rw_trans(struct spi_message *m,
 		return;
 	}
 
-	for (pos = 0, loop = 0; pos < n_rx; pos += trans_len, loop++) {
-		trans_len = n_rx - pos;
-		if (trans_len > SPCOM_TRANLEN_MAX - n_tx)
-			trans_len = SPCOM_TRANLEN_MAX - n_tx;
+	for (pos = 0, loop = 0; pos < total_len; pos += trans_len, loop++) {
+		trans_len = total_len - pos;
 
 		i = 0;
+		tx_only = 0;
 		list_for_each_entry(t, &m->transfers, transfer_list) {
 			if (t->tx_buf) {
 				memcpy(local_buf + i, t->tx_buf, t->len);
 				i += t->len;
+				if (!t->rx_buf)
+					tx_only += t->len;
 			}
 		}
 
+		/* Add additional TX bytes to compensate SPCOM_TRANLEN_MAX */
+		if (loop > 0)
+			trans_len += tx_only;
+
+		if (trans_len > SPCOM_TRANLEN_MAX)
+			trans_len = SPCOM_TRANLEN_MAX;
+
+		/* Update device offset */
 		if (pos > 0) {
 			addr = fsl_espi_cmd2addr(local_buf);
-			addr += pos;
+			addr += rx_pos;
 			fsl_espi_addr2cmd(addr, local_buf);
 		}
 
-		espi_trans->n_tx = n_tx;
-		espi_trans->n_rx = trans_len;
-		espi_trans->len = trans_len + n_tx;
+		espi_trans->len = trans_len;
 		espi_trans->tx_buf = local_buf;
 		espi_trans->rx_buf = local_buf;
 		fsl_espi_do_trans(m, espi_trans);
 
-		memcpy(rx_buf + pos, espi_trans->rx_buf + n_tx, trans_len);
+		/* If there is at least one RX byte then copy it to rx_buf */
+		if (tx_only < SPCOM_TRANLEN_MAX)
+			memcpy(rx_buf + rx_pos, espi_trans->rx_buf + tx_only,
+					trans_len - tx_only);
+
+		rx_pos += trans_len - tx_only;
 
 		if (loop > 0)
-			espi_trans->actual_length += espi_trans->len - n_tx;
+			espi_trans->actual_length += espi_trans->len - tx_only;
 		else
 			espi_trans->actual_length += espi_trans->len;
 	}
@@ -418,6 +432,7 @@ static int fsl_espi_do_one_msg(struct spi_master *master,
 	u8 *rx_buf = NULL;
 	unsigned int n_tx = 0;
 	unsigned int n_rx = 0;
+	unsigned int xfer_len = 0;
 	struct fsl_espi_transfer espi_trans;
 
 	list_for_each_entry(t, &m->transfers, transfer_list) {
@@ -427,11 +442,13 @@ static int fsl_espi_do_one_msg(struct spi_master *master,
 			n_rx += t->len;
 			rx_buf = t->rx_buf;
 		}
+		if ((t->tx_buf) || (t->rx_buf))
+			xfer_len += t->len;
 	}
 
 	espi_trans.n_tx = n_tx;
 	espi_trans.n_rx = n_rx;
-	espi_trans.len = n_tx + n_rx;
+	espi_trans.len = xfer_len;
 	espi_trans.actual_length = 0;
 	espi_trans.status = 0;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
  2015-04-15 15:23 ` Jonatas Rech
  (?)
@ 2015-04-18 12:55 ` Mark Brown
  2015-04-22 15:09     ` DATACOM - Jonatas.Rech
  -1 siblings, 1 reply; 13+ messages in thread
From: Mark Brown @ 2015-04-18 12:55 UTC (permalink / raw)
  To: Jonatas Rech; +Cc: linux-spi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Wed, Apr 15, 2015 at 12:23:18PM -0300, Jonatas Rech wrote:

> Furthermore, this correction has exposed an inconsistency in the
> protocol driver <-> controller driver interaction. The spi-fsl-espi
> driver artificially inserts TX bytes when message fragmentation is
> necessary (due to SPCOM_TRANLEN_MAX) instead of informing the
> protocol driver of the hardware limitation. This was tested with the
> m25p80 NOR flash protocol driver. Since fixing this issue may cause
> other client drivers to malfunction, it was left as is.

Sorry, you're saying that the driver is sending more data than it's
being asked to in some situations?  That is a *very* serious bug in both
this driver and any other driver which relies on (as opposed to merely
tolerates) this behaviour.  If that is the case it really needs to be
fixed fairly urgently.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-22 15:09     ` DATACOM - Jonatas.Rech
  0 siblings, 0 replies; 13+ messages in thread
From: DATACOM - Jonatas.Rech @ 2015-04-22 15:09 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-spi, linux-kernel

That's right.

The m25p80 driver can send down a message that's bigger than the amount the spi-fsl-espi driver can handle in a single espi_transfer (64KiB), when the application wants to read the whole memory content, for instance. In this case, the Freescale driver splits the message in 64KiB chunks, adding a "Read the next 64KiB" command in the TX buffer so the flash memory can output data from the expected offset. In the end, the m25p80 driver sees all the data as one big rx_buf, as it expected in the first place.

I don't think a controller driver should make this kind of assumption on how protocol (slave device) drivers intend to use it. Instead, I think this kind of intelligence (about fragmentation and replaying of TX commands) should be in the protocol drivers themselves, aware of the maximum message length the hardware can handle.

Unfortunately, I don't know how many protocol drivers currently rely on this, or even how other controller drivers deal with this expected behavior.


----- Original Message -----
From: "Mark Brown" <broonie@kernel.org>
To: "DATACOM" <jonatas.rech@datacom.ind.br>
Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Sent: Saturday, April 18, 2015 9:55:56 AM
Subject: Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers

On Wed, Apr 15, 2015 at 12:23:18PM -0300, Jonatas Rech wrote:

> Furthermore, this correction has exposed an inconsistency in the
> protocol driver <-> controller driver interaction. The spi-fsl-espi
> driver artificially inserts TX bytes when message fragmentation is
> necessary (due to SPCOM_TRANLEN_MAX) instead of informing the
> protocol driver of the hardware limitation. This was tested with the
> m25p80 NOR flash protocol driver. Since fixing this issue may cause
> other client drivers to malfunction, it was left as is.

Sorry, you're saying that the driver is sending more data than it's
being asked to in some situations?  That is a *very* serious bug in both
this driver and any other driver which relies on (as opposed to merely
tolerates) this behaviour.  If that is the case it really needs to be
fixed fairly urgently.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-22 15:09     ` DATACOM - Jonatas.Rech
  0 siblings, 0 replies; 13+ messages in thread
From: DATACOM - Jonatas.Rech @ 2015-04-22 15:09 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA

That's right.

The m25p80 driver can send down a message that's bigger than the amount the spi-fsl-espi driver can handle in a single espi_transfer (64KiB), when the application wants to read the whole memory content, for instance. In this case, the Freescale driver splits the message in 64KiB chunks, adding a "Read the next 64KiB" command in the TX buffer so the flash memory can output data from the expected offset. In the end, the m25p80 driver sees all the data as one big rx_buf, as it expected in the first place.

I don't think a controller driver should make this kind of assumption on how protocol (slave device) drivers intend to use it. Instead, I think this kind of intelligence (about fragmentation and replaying of TX commands) should be in the protocol drivers themselves, aware of the maximum message length the hardware can handle.

Unfortunately, I don't know how many protocol drivers currently rely on this, or even how other controller drivers deal with this expected behavior.


----- Original Message -----
From: "Mark Brown" <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: "DATACOM" <jonatas.rech-rCUF4CxDseZknzVnJbg3IA@public.gmane.org>
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Sent: Saturday, April 18, 2015 9:55:56 AM
Subject: Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers

On Wed, Apr 15, 2015 at 12:23:18PM -0300, Jonatas Rech wrote:

> Furthermore, this correction has exposed an inconsistency in the
> protocol driver <-> controller driver interaction. The spi-fsl-espi
> driver artificially inserts TX bytes when message fragmentation is
> necessary (due to SPCOM_TRANLEN_MAX) instead of informing the
> protocol driver of the hardware limitation. This was tested with the
> m25p80 NOR flash protocol driver. Since fixing this issue may cause
> other client drivers to malfunction, it was left as is.

Sorry, you're saying that the driver is sending more data than it's
being asked to in some situations?  That is a *very* serious bug in both
this driver and any other driver which relies on (as opposed to merely
tolerates) this behaviour.  If that is the case it really needs to be
fixed fairly urgently.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
  2015-04-22 15:09     ` DATACOM - Jonatas.Rech
  (?)
@ 2015-04-22 19:57     ` Mark Brown
  2015-04-23 18:06         ` Jonatas Rech
  -1 siblings, 1 reply; 13+ messages in thread
From: Mark Brown @ 2015-04-22 19:57 UTC (permalink / raw)
  To: DATACOM - Jonatas.Rech; +Cc: linux-spi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

On Wed, Apr 22, 2015 at 12:09:03PM -0300, DATACOM - Jonatas.Rech wrote:

Don't top post (context is important for people to know what you are
talking about) and please fix your mailer to word wrap within
paragraphs so your mail can be read and replied to more readily.

> The m25p80 driver can send down a message that's bigger than the
> amount the spi-fsl-espi driver can handle in a single espi_transfer
> (64KiB), when the application wants to read the whole memory content,
> for instance. In this case, the Freescale driver splits the message in
> 64KiB chunks, adding a "Read the next 64KiB" command in the TX buffer
> so the flash memory can output data from the expected offset. In the
> end, the m25p80 driver sees all the data as one big rx_buf, as it
> expected in the first place.

This is completely broken.

> Unfortunately, I don't know how many protocol drivers currently rely
> on this, or even how other controller drivers deal with this expected
> behavior.

This is not expected behaviour for anything and should be fixed
urgently.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-23 18:06         ` Jonatas Rech
  0 siblings, 0 replies; 13+ messages in thread
From: Jonatas Rech @ 2015-04-23 18:06 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-spi, linux-kernel

On Wed, Apr 22, 2015 at 08:57:46PM +0100, Mark Brown wrote:
> On Wed, Apr 22, 2015 at 12:09:03PM -0300, DATACOM - Jonatas.Rech wrote:
> 
> Don't top post (context is important for people to know what you are
> talking about) and please fix your mailer to word wrap within
> paragraphs so your mail can be read and replied to more readily.
> 

I'm sorry for that, thanks for the heads-up.

> > The m25p80 driver can send down a message that's bigger than the
> > amount the spi-fsl-espi driver can handle in a single espi_transfer
> > (64KiB), when the application wants to read the whole memory content,
> > for instance. In this case, the Freescale driver splits the message in
> > 64KiB chunks, adding a "Read the next 64KiB" command in the TX buffer
> > so the flash memory can output data from the expected offset. In the
> > end, the m25p80 driver sees all the data as one big rx_buf, as it
> > expected in the first place.
> 
> This is completely broken.
> 
> > Unfortunately, I don't know how many protocol drivers currently rely
> > on this, or even how other controller drivers deal with this expected
> > behavior.
> 
> This is not expected behaviour for anything and should be fixed
> urgently.

I agree, but please note that this came up while I was trying to fix the
full-duplex functionality, and it's a different problem. Fixing this would
impact protocol drivers, as stated earlier. It would take some time for me to
study other drivers and come up with the best solution for this driver plus
(at least) the m25p80, which supports the hardware I currently have access to.

I know this must be fixed, but wouldn't it be subject to a different patch?
Thanks in advance for the advice.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-23 18:06         ` Jonatas Rech
  0 siblings, 0 replies; 13+ messages in thread
From: Jonatas Rech @ 2015-04-23 18:06 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Wed, Apr 22, 2015 at 08:57:46PM +0100, Mark Brown wrote:
> On Wed, Apr 22, 2015 at 12:09:03PM -0300, DATACOM - Jonatas.Rech wrote:
> 
> Don't top post (context is important for people to know what you are
> talking about) and please fix your mailer to word wrap within
> paragraphs so your mail can be read and replied to more readily.
> 

I'm sorry for that, thanks for the heads-up.

> > The m25p80 driver can send down a message that's bigger than the
> > amount the spi-fsl-espi driver can handle in a single espi_transfer
> > (64KiB), when the application wants to read the whole memory content,
> > for instance. In this case, the Freescale driver splits the message in
> > 64KiB chunks, adding a "Read the next 64KiB" command in the TX buffer
> > so the flash memory can output data from the expected offset. In the
> > end, the m25p80 driver sees all the data as one big rx_buf, as it
> > expected in the first place.
> 
> This is completely broken.
> 
> > Unfortunately, I don't know how many protocol drivers currently rely
> > on this, or even how other controller drivers deal with this expected
> > behavior.
> 
> This is not expected behaviour for anything and should be fixed
> urgently.

I agree, but please note that this came up while I was trying to fix the
full-duplex functionality, and it's a different problem. Fixing this would
impact protocol drivers, as stated earlier. It would take some time for me to
study other drivers and come up with the best solution for this driver plus
(at least) the m25p80, which supports the hardware I currently have access to.

I know this must be fixed, but wouldn't it be subject to a different patch?
Thanks in advance for the advice.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
  2015-04-23 18:06         ` Jonatas Rech
  (?)
@ 2015-04-24 18:17         ` Mark Brown
  2015-04-24 20:03             ` Jonatas Rech
  -1 siblings, 1 reply; 13+ messages in thread
From: Mark Brown @ 2015-04-24 18:17 UTC (permalink / raw)
  To: Jonatas Rech; +Cc: linux-spi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

On Thu, Apr 23, 2015 at 03:06:22PM -0300, Jonatas Rech wrote:

> I agree, but please note that this came up while I was trying to fix the
> full-duplex functionality, and it's a different problem. Fixing this would
> impact protocol drivers, as stated earlier. It would take some time for me to
> study other drivers and come up with the best solution for this driver plus
> (at least) the m25p80, which supports the hardware I currently have access to.

> I know this must be fixed, but wouldn't it be subject to a different patch?
> Thanks in advance for the advice.

The commit message says "this correction has exposed an inconsistency"
which suggests that the problem was masked before this fix.  Did you
mean to say that while fixing this you noticed a separate bug that's
present anyway?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-24 20:03             ` Jonatas Rech
  0 siblings, 0 replies; 13+ messages in thread
From: Jonatas Rech @ 2015-04-24 20:03 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-spi, linux-kernel

On Fri, Apr 24, 2015 at 07:17:45PM +0100, Mark Brown wrote:
> On Thu, Apr 23, 2015 at 03:06:22PM -0300, Jonatas Rech wrote:
> 
> > I agree, but please note that this came up while I was trying to fix the
> > full-duplex functionality, and it's a different problem. Fixing this would
> > impact protocol drivers, as stated earlier. It would take some time for me to
> > study other drivers and come up with the best solution for this driver plus
> > (at least) the m25p80, which supports the hardware I currently have access to.
> 
> > I know this must be fixed, but wouldn't it be subject to a different patch?
> > Thanks in advance for the advice.
> 
> The commit message says "this correction has exposed an inconsistency"
> which suggests that the problem was masked before this fix.  Did you
> mean to say that while fixing this you noticed a separate bug that's
> present anyway?

Exactly. Besides fixing the full-duplex capability I reorganized things
inside the main loop so that anybody can spot where the extra bytes are
being sent, but the code works just the same as before in that respect.

My guess is that, appart from memory chips, most SPI devices are
accessed with short transfers, and since this only arises when one wants
to read/write more than 64KiB at once, it has remained unnoticed. So, as
long as flash memories work with this driver (and they do, because of
the bug), there won't be the need for it to be fixed. Apparently it was
implemented this way on purpose by the original author.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-24 20:03             ` Jonatas Rech
  0 siblings, 0 replies; 13+ messages in thread
From: Jonatas Rech @ 2015-04-24 20:03 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA

On Fri, Apr 24, 2015 at 07:17:45PM +0100, Mark Brown wrote:
> On Thu, Apr 23, 2015 at 03:06:22PM -0300, Jonatas Rech wrote:
> 
> > I agree, but please note that this came up while I was trying to fix the
> > full-duplex functionality, and it's a different problem. Fixing this would
> > impact protocol drivers, as stated earlier. It would take some time for me to
> > study other drivers and come up with the best solution for this driver plus
> > (at least) the m25p80, which supports the hardware I currently have access to.
> 
> > I know this must be fixed, but wouldn't it be subject to a different patch?
> > Thanks in advance for the advice.
> 
> The commit message says "this correction has exposed an inconsistency"
> which suggests that the problem was masked before this fix.  Did you
> mean to say that while fixing this you noticed a separate bug that's
> present anyway?

Exactly. Besides fixing the full-duplex capability I reorganized things
inside the main loop so that anybody can spot where the extra bytes are
being sent, but the code works just the same as before in that respect.

My guess is that, appart from memory chips, most SPI devices are
accessed with short transfers, and since this only arises when one wants
to read/write more than 64KiB at once, it has remained unnoticed. So, as
long as flash memories work with this driver (and they do, because of
the bug), there won't be the need for it to be fixed. Apparently it was
implemented this way on purpose by the original author.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-25 13:01               ` Mark Brown
  0 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2015-04-25 13:01 UTC (permalink / raw)
  To: Jonatas Rech; +Cc: linux-spi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Fri, Apr 24, 2015 at 05:03:26PM -0300, Jonatas Rech wrote:
> On Fri, Apr 24, 2015 at 07:17:45PM +0100, Mark Brown wrote:

> > The commit message says "this correction has exposed an inconsistency"
> > which suggests that the problem was masked before this fix.  Did you
> > mean to say that while fixing this you noticed a separate bug that's
> > present anyway?

> Exactly. Besides fixing the full-duplex capability I reorganized things
> inside the main loop so that anybody can spot where the extra bytes are
> being sent, but the code works just the same as before in that respect.

OK, please be clear when writing changelogs - it makes life easier.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers
@ 2015-04-25 13:01               ` Mark Brown
  0 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2015-04-25 13:01 UTC (permalink / raw)
  To: Jonatas Rech
  Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On Fri, Apr 24, 2015 at 05:03:26PM -0300, Jonatas Rech wrote:
> On Fri, Apr 24, 2015 at 07:17:45PM +0100, Mark Brown wrote:

> > The commit message says "this correction has exposed an inconsistency"
> > which suggests that the problem was masked before this fix.  Did you
> > mean to say that while fixing this you noticed a separate bug that's
> > present anyway?

> Exactly. Besides fixing the full-duplex capability I reorganized things
> inside the main loop so that anybody can spot where the extra bytes are
> being sent, but the code works just the same as before in that respect.

OK, please be clear when writing changelogs - it makes life easier.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2015-04-25 13:01 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-15 15:23 [PATCH] spi: fsl-espi: fix behaviour for full-duplex xfers Jonatas Rech
2015-04-15 15:23 ` Jonatas Rech
2015-04-18 12:55 ` Mark Brown
2015-04-22 15:09   ` DATACOM - Jonatas.Rech
2015-04-22 15:09     ` DATACOM - Jonatas.Rech
2015-04-22 19:57     ` Mark Brown
2015-04-23 18:06       ` Jonatas Rech
2015-04-23 18:06         ` Jonatas Rech
2015-04-24 18:17         ` Mark Brown
2015-04-24 20:03           ` Jonatas Rech
2015-04-24 20:03             ` Jonatas Rech
2015-04-25 13:01             ` Mark Brown
2015-04-25 13:01               ` Mark Brown

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.