| Message ID | 1429111398-21444-1-git-send-email-jonatas.rech@datacom.ind.br (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 2000058e892cd6773b3061a56c0bd6535ac15afe |
| Headers | show |
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.
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. -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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?
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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;
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(-)