Message ID | 20161108134624.1905209-1-arnd@arndb.de (mailing list archive) |
---|---|
State | Accepted |
Commit | db30083813b559e98e10ae26bd09d3dc69be7fb7 |
Headers | show |
Since I was CC-ed, I'll add in my opinion: While Geert already pointed out the spelling mistake (_in_or_our >> _in_or_out), since that function is only just for qspi versions, a better function name should have been "qspi_pio_transfer_in_or_out" However.... On 11/8/2016, Arnd Bergmann wrote: > This simplifies it again by keeping the two separate, which then ends up > avoiding that warning. I agree with Arnd's method of NOT adding a new "rspi_pio_transfer_in_or_our" function and instead just doing it in the existing qspi_transfer_ functions. Side note: The RSPI in the RZ/A1 devices also have FIFOs which can be used to reduce the number of interrupts in pio transfers, so maybe someday I'll make a similar change for non-qspi devices as well. Chris -- 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 Tue, Nov 08, 2016 at 05:20:50PM +0000, Chris Brandt wrote: > Since I was CC-ed, I'll add in my opinion: > While Geert already pointed out the spelling mistake (_in_or_our >> _in_or_out), since that function is only just for qspi versions, a better function name should have been "qspi_pio_transfer_in_or_out" Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed. Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to.
On Tue, Nov 8, 2016 at 6:20 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote: > However.... > > On 11/8/2016, Arnd Bergmann wrote: >> This simplifies it again by keeping the two separate, which then ends up >> avoiding that warning. > > I agree with Arnd's method of NOT adding a new "rspi_pio_transfer_in_or_our" > function and instead just doing it in the existing qspi_transfer_ functions. > > Side note: The RSPI in the RZ/A1 devices also have FIFOs which can be used > to reduce the number of interrupts in pio transfers, so maybe someday I'll > make a similar change for non-qspi devices as well. At which point we probably want to extract the functionality into two separate functions again, instead of inlining into qspi_transfer_{in,out}()... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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
Hi Arnd, Thanks for your fixed patch. On 11/08/2016 10:46 PM, Arnd Bergmann wrote: > The newly introduced rspi_pio_transfer_in_or_our() function must > take either a valid 'rx' or 'tx' pointer, and has undefined behavior > if both are NULL, as found by 'gcc -Wmaybe-unintialized': > > drivers/spi/spi-rspi.c: In function 'rspi_pio_transfer_in_or_our': > drivers/spi/spi-rspi.c:558:5: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized] Could you tell me what kind of GCC are you using? I'd like to reproduce it on my environment, too. I am using the Linaro's gcc of "gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux". But there is no error message like this on my environment. Best regards, Jinzai Solution Inc, Hiep. -- 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 Thursday, November 10, 2016 6:25:56 PM CET Hiep Cao Minh wrote: > Hi Arnd, > > Thanks for your fixed patch. > > On 11/08/2016 10:46 PM, Arnd Bergmann wrote: > > The newly introduced rspi_pio_transfer_in_or_our() function must > > take either a valid 'rx' or 'tx' pointer, and has undefined behavior > > if both are NULL, as found by 'gcc -Wmaybe-unintialized': > > > > drivers/spi/spi-rspi.c: In function 'rspi_pio_transfer_in_or_our': > > drivers/spi/spi-rspi.c:558:5: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized] > Could you tell me what kind of GCC are you using? > I'd like to reproduce it on my environment, too. > I am using the Linaro's gcc of > "gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux". > But there is no error message like this on my environment. The warning is currently disabled in mainline Linux, but I'm trying to address this and hope to still get a revert of 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally") into v4.9. You can build with "make EXTRA_CFLAGS=-Wmaybe-uninitialized" in the meantime. Arnd -- 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
Hi Arnd, On 11/10/2016 07:51 PM, Arnd Bergmann wrote: > On Thursday, November 10, 2016 6:25:56 PM CET Hiep Cao Minh wrote: >> Hi Arnd, >> >> Thanks for your fixed patch. >> >> On 11/08/2016 10:46 PM, Arnd Bergmann wrote: >>> The newly introduced rspi_pio_transfer_in_or_our() function must >>> take either a valid 'rx' or 'tx' pointer, and has undefined behavior >>> if both are NULL, as found by 'gcc -Wmaybe-unintialized': >>> >>> drivers/spi/spi-rspi.c: In function 'rspi_pio_transfer_in_or_our': >>> drivers/spi/spi-rspi.c:558:5: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized] >> Could you tell me what kind of GCC are you using? >> I'd like to reproduce it on my environment, too. >> I am using the Linaro's gcc of >> "gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux". >> But there is no error message like this on my environment. > The warning is currently disabled in mainline Linux, but I'm trying to > address this and hope to still get a revert of 6e8d666e9253 ("Disable > "maybe-uninitialized" warning globally") into v4.9. > > You can build with "make EXTRA_CFLAGS=-Wmaybe-uninitialized" in > the meantime. Thanks, I used your command and found the warning. Best regards, Hiep Jinzai Solution Inc, -- 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
diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c index 3bab75ab1b25..9daf50031737 100644 --- a/drivers/spi/spi-rspi.c +++ b/drivers/spi/spi-rspi.c @@ -515,51 +515,6 @@ static int rspi_pio_transfer(struct rspi_data *rspi, const u8 *tx, u8 *rx, return 0; } -static int rspi_pio_transfer_in_or_our(struct rspi_data *rspi, const u8 *tx, - u8 *rx, unsigned int n) -{ - unsigned int i, len; - int ret; - - while (n > 0) { - if (tx) { - len = qspi_set_send_trigger(rspi, n); - if (len == QSPI_BUFFER_SIZE) { - ret = rspi_wait_for_tx_empty(rspi); - if (ret < 0) { - dev_err(&rspi->master->dev, "transmit timeout\n"); - return ret; - } - for (i = 0; i < len; i++) - rspi_write_data(rspi, *tx++); - } else { - ret = rspi_pio_transfer(rspi, tx, NULL, n); - if (ret < 0) - return ret; - } - } - if (rx) { - len = qspi_set_receive_trigger(rspi, n); - if (len == QSPI_BUFFER_SIZE) { - ret = rspi_wait_for_rx_full(rspi); - if (ret < 0) { - dev_err(&rspi->master->dev, "receive timeout\n"); - return ret; - } - for (i = 0; i < len; i++) - *rx++ = rspi_read_data(rspi); - } else { - ret = rspi_pio_transfer(rspi, NULL, rx, n); - if (ret < 0) - return ret; - *rx++ = ret; - } - } - n -= len; - } - return 0; -} - static void rspi_dma_complete(void *arg) { struct rspi_data *rspi = arg; @@ -831,6 +786,9 @@ static int qspi_transfer_out_in(struct rspi_data *rspi, static int qspi_transfer_out(struct rspi_data *rspi, struct spi_transfer *xfer) { + const u8 *tx = xfer->tx_buf; + unsigned int n = xfer->len; + unsigned int i, len; int ret; if (rspi->master->can_dma && __rspi_can_dma(rspi, xfer)) { @@ -839,9 +797,23 @@ static int qspi_transfer_out(struct rspi_data *rspi, struct spi_transfer *xfer) return ret; } - ret = rspi_pio_transfer_in_or_our(rspi, xfer->tx_buf, NULL, xfer->len); - if (ret < 0) - return ret; + while (n > 0) { + len = qspi_set_send_trigger(rspi, n); + if (len == QSPI_BUFFER_SIZE) { + ret = rspi_wait_for_tx_empty(rspi); + if (ret < 0) { + dev_err(&rspi->master->dev, "transmit timeout\n"); + return ret; + } + for (i = 0; i < len; i++) + rspi_write_data(rspi, *tx++); + } else { + ret = rspi_pio_transfer(rspi, tx, NULL, n); + if (ret < 0) + return ret; + } + n -= len; + } /* Wait for the last transmission */ rspi_wait_for_tx_empty(rspi); @@ -851,13 +823,37 @@ static int qspi_transfer_out(struct rspi_data *rspi, struct spi_transfer *xfer) static int qspi_transfer_in(struct rspi_data *rspi, struct spi_transfer *xfer) { + u8 *rx = xfer->rx_buf; + unsigned int n = xfer->len; + unsigned int i, len; + int ret; + if (rspi->master->can_dma && __rspi_can_dma(rspi, xfer)) { int ret = rspi_dma_transfer(rspi, NULL, &xfer->rx_sg); if (ret != -EAGAIN) return ret; } - return rspi_pio_transfer_in_or_our(rspi, NULL, xfer->rx_buf, xfer->len); + while (n > 0) { + len = qspi_set_receive_trigger(rspi, n); + if (len == QSPI_BUFFER_SIZE) { + ret = rspi_wait_for_rx_full(rspi); + if (ret < 0) { + dev_err(&rspi->master->dev, "receive timeout\n"); + return ret; + } + for (i = 0; i < len; i++) + *rx++ = rspi_read_data(rspi); + } else { + ret = rspi_pio_transfer(rspi, NULL, rx, n); + if (ret < 0) + return ret; + *rx++ = ret; + } + n -= len; + } + + return 0; } static int qspi_transfer_one(struct spi_master *master, struct spi_device *spi,
The newly introduced rspi_pio_transfer_in_or_our() function must take either a valid 'rx' or 'tx' pointer, and has undefined behavior if both are NULL, as found by 'gcc -Wmaybe-unintialized': drivers/spi/spi-rspi.c: In function 'rspi_pio_transfer_in_or_our': drivers/spi/spi-rspi.c:558:5: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized] The analysis of the function is correct in principle, but the code is currently safe because both callers always pass exactly one of the two pointers. Looking closer at this function shows that having a combined method for rx and tx here actually increases the complexity and the size of the file. This simplifies it again by keeping the two separate, which then ends up avoiding that warning. Fixes: 3be09bec42a8 ("spi: rspi: supports 32bytes buffer for DUAL and QUAD") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/spi/spi-rspi.c | 94 ++++++++++++++++++++++++-------------------------- 1 file changed, 45 insertions(+), 49 deletions(-)