| Message ID | 1453460307-9768-2-git-send-email-Zhiqiang.Hou@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jan 22, 2016 at 06:58:27PM +0800, Zhiqiang Hou wrote: > From: Hou Zhiqiang <B48286@freescale.com> > > The eSPI bus driver should not touch the protocol layer drivers' > operations. It makes the eSPI driver isn't compatiable with devices I don't seem to have patch 1.
On Fri, Jan 22, 2016 at 11:26:37AM +0000, Mark Brown wrote: > On Fri, Jan 22, 2016 at 06:58:27PM +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang <B48286@freescale.com> > > > > The eSPI bus driver should not touch the protocol layer drivers' > > operations. It makes the eSPI driver isn't compatiable with devices > > I don't seem to have patch 1. It turned up now.
On Fri, Jan 22, 2016 at 06:58:27PM +0800, Zhiqiang Hou wrote: > Tested on T1042D4RDB. > This patch depend on patchset: > http://patchwork.ozlabs.org/patch/551304/ > http://patchwork.ozlabs.org/patch/551308/ > http://patchwork.ozlabs.org/patch/551305/ > http://patchwork.ozlabs.org/patch/551306/ > http://patchwork.ozlabs.org/patch/551309/ > http://patchwork.ozlabs.org/patch/551307/ > http://patchwork.ozlabs.org/patch/551310/ > http://patchwork.ozlabs.org/patch/551311/ > and patch: > http://patchwork.ozlabs.org/patch/571581/ This is a *very* large list of dependencies. What exactly are these and what is the relationship between them and this patch? Please include human readable descriptions of things like commits and issues being discussed in e-mail in your mails, this makes them much easier for humans to read especially when they have no internet access. I do frequently catch up on my mail on flights or while otherwise travelling so this is even more pressing for me than just being about making things a bit easier to read.
Hi Mark, Thanks for your comments! > -----Original Message----- > From: Mark Brown [mailto:broonie@kernel.org] > Sent: 2016?1?23? 1:03 > To: Zhiqiang Hou <Zhiqiang.Hou@freescale.com> > Cc: linux-spi@vger.kernel.org; computersforpeace@gmail.com; > hramrach@gmail.com; Mingkai.Hu@freescale.com; Shaohui.Xie@freescale.com; > Hou Zhiqiang <B48286@freescale.com> > Subject: Re: [PATCH 2/2] spi/fsl-espi: Remove the address conversion operation > > On Fri, Jan 22, 2016 at 06:58:27PM +0800, Zhiqiang Hou wrote: > > > Tested on T1042D4RDB. > > This patch depend on patchset: > > http://patchwork.ozlabs.org/patch/551304/ patch title: [v6,01/10] mtd: spi-nor: change return value of read/write Change the return value of spi-nor device read and write methods to allow returning amount of data transferred and errors as read(2)/write(2) does. > > http://patchwork.ozlabs.org/patch/551308/[] patch title: [v6,02/10] mtd: m25p80: return amount of data transferred or error in read/write Add checking of SPI transfer errors and return them from read/write functions. Also return the amount of data transferred. > > http://patchwork.ozlabs.org/patch/551305/ patch title: [v6,03/10] mtd: fsl-quadspi: return amount of data read/written or error Return amount of data read/written or error as read(2)/write(2) does. > > http://patchwork.ozlabs.org/patch/551306/ patch title: [v6,04/10] mtd: spi-nor: check return value from read/write SPI NOR hardware drivers now return useful value from their read/write functions so check them. > > http://patchwork.ozlabs.org/patch/551309/ patch title: [v6,05/10] mtd: spi-nor: stop passing around retlen Do not pass retlen to hardware driver read/write functions. Update it in spi-nor generic driver instead. > > http://patchwork.ozlabs.org/patch/551307/ patch title: [v6,06/10] mtd: spi-nor: simplify write loop The spi-nor write loop assumes that what is passed to the hardware driver write() is what gets written. When write() writes less than page size at once data is dropped on the floor. Check the amount of data writen and exit if it does not match requested amount. > > http://patchwork.ozlabs.org/patch/551310/ patch title: [v6,07/10] mtd: spi-nor: add read loop mtdblock and ubi do not handle the situation when read returns less data than requested. Loop in spi-nor until buffer is filled or an error is returned. > > http://patchwork.ozlabs.org/patch/551311/[] patch title: [v6,10/10] mtd: m25p80: read in spi_max_transfer_size chunks Take into account transfer size limitation of SPI master. Those is a patchset that has 10 patches and 2 of them has been merged, so I pasted the remnant as the dependence. The patch [v6,03/10] mtd: fsl-quadspi: return amount of data read/written or error and [v6,06/10] mtd: spi-nor: simplify write loop is not depended. The others of this patchset is depended, as the removed protocol layer's operations from eSPI controller driver were handled by this patchset. > > and patch: > > http://patchwork.ozlabs.org/patch/571581/ patch title: dts/fsl/powerpc: add "jedec, spi-nor" flash compatible binding This patch is not a code dependency but test need, upon the latest code base the m25p80 driver will failed to probe, I added this patch to make others can reproduce the test. > > This is a *very* large list of dependencies. What exactly are these and what is the > relationship between them and this patch? > > Please include human readable descriptions of things like commits and issues being > discussed in e-mail in your mails, this makes them much easier for humans to read > especially when they have no internet access. > I do frequently catch up on my mail on flights or while otherwise travelling so this > is even more pressing for me than just being about making things a bit easier to > read. yes, thanks for your advice. Thanks, Zhiqiang
On Mon, Jan 25, 2016 at 05:47:33AM +0000, Zhiqiang Hou wrote: > > This is a *very* large list of dependencies. What exactly are these and what is the > > relationship between them and this patch? > > Please include human readable descriptions of things like commits and issues being > > discussed in e-mail in your mails, this makes them much easier for humans to read > > especially when they have no internet access. > > I do frequently catch up on my mail on flights or while otherwise travelling so this > > is even more pressing for me than just being about making things a bit easier to > > read. > yes, thanks for your advice. I still can't really tell what's going on here or where these dependencies are at. Probably the easiest thing here is to submit this once the dependencies are in.
diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c index 7cb0c19..66ebb02 100644 --- a/drivers/spi/spi-fsl-espi.c +++ b/drivers/spi/spi-fsl-espi.c @@ -253,23 +253,6 @@ static int fsl_espi_bufs(struct spi_device *spi, struct spi_transfer *t) return mpc8xxx_spi->count; } -static inline void fsl_espi_addr2cmd(unsigned int addr, u8 *cmd) -{ - if (cmd) { - cmd[1] = (u8)(addr >> 16); - cmd[2] = (u8)(addr >> 8); - cmd[3] = (u8)(addr >> 0); - } -} - -static inline unsigned int fsl_espi_cmd2addr(u8 *cmd) -{ - if (cmd) - return cmd[1] << 16 | cmd[2] << 8 | cmd[3] << 0; - - return 0; -} - static void fsl_espi_do_trans(struct spi_message *m, struct fsl_espi_transfer *tr) { @@ -366,12 +349,9 @@ static void fsl_espi_rw_trans(struct spi_message *m, struct spi_transfer *t; u8 *local_buf; u8 *rx_buf = rx_buff; - unsigned int trans_len; - unsigned int addr; - unsigned int tx_only; - unsigned int rx_pos = 0; - unsigned int pos; - int i, loop; + unsigned int trans_len = total_len; + unsigned int tx_only = 0; + int i = 0; local_buf = kzalloc(SPCOM_TRANLEN_MAX, GFP_KERNEL); if (!local_buf) { @@ -379,51 +359,29 @@ static void fsl_espi_rw_trans(struct spi_message *m, return; } - 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 += rx_pos; - fsl_espi_addr2cmd(addr, local_buf); + 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; } + } - espi_trans->len = trans_len; - espi_trans->tx_buf = local_buf; - espi_trans->rx_buf = local_buf; - fsl_espi_do_trans(m, espi_trans); + if (trans_len > SPCOM_TRANLEN_MAX) + trans_len = SPCOM_TRANLEN_MAX; - /* 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); + espi_trans->len = trans_len; + espi_trans->tx_buf = local_buf; + espi_trans->rx_buf = local_buf; + fsl_espi_do_trans(m, espi_trans); - rx_pos += trans_len - tx_only; + /* If there is at least one RX byte then copy it to rx_buf */ + if (tx_only < SPCOM_TRANLEN_MAX) + memcpy(rx_buf, espi_trans->rx_buf + tx_only, + trans_len - tx_only); - if (loop > 0) - espi_trans->actual_length += espi_trans->len - tx_only; - else - espi_trans->actual_length += espi_trans->len; - } + espi_trans->actual_length += espi_trans->len; kfree(local_buf); }