Re: [U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers

2014-04-14 Thread Jagan Teki
On Fri, Apr 11, 2014 at 12:47 AM, Andrew Ruder wrote: > On Fri, Apr 11, 2014 at 12:33:45AM +0530, Jagan Teki wrote: >> >> It would be great if you mentioned issue scenario for status poll case >> >> drivers/mtd/spi/sf_ops.c: ret = spi_xfer(spi, 8, NULL, >> >> &status, 0); >> OK - mea

Re: [U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers

2014-04-10 Thread Andrew Ruder
On Fri, Apr 11, 2014 at 12:33:45AM +0530, Jagan Teki wrote: > >> It would be great if you mentioned issue scenario for status poll case > >> drivers/mtd/spi/sf_ops.c: ret = spi_xfer(spi, 8, NULL, > >> &status, 0); > OK - means issue only with soft_spi.c is it? Yes, and a couple other

Re: [U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers

2014-04-10 Thread Jagan Teki
On Fri, Apr 11, 2014 at 12:27 AM, Andrew Ruder wrote: > On Fri, Apr 11, 2014 at 12:24:20AM +0530, Jagan Teki wrote: >> At-least from zynq_spi.c case - I wouldn't find that obscure case as you >> pointed >> and even with dout NULL which is status poll from (sf_ops.c). > > zynq_spi is correct, soft

Re: [U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers

2014-04-10 Thread Andrew Ruder
On Fri, Apr 11, 2014 at 12:24:20AM +0530, Jagan Teki wrote: > At-least from zynq_spi.c case - I wouldn't find that obscure case as you > pointed > and even with dout NULL which is status poll from (sf_ops.c). zynq_spi is correct, soft_spi is not. zynq_spi.c: int spi_xfer(struct spi_slave *slave,

Re: [U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers

2014-04-10 Thread Jagan Teki
On Thu, Apr 10, 2014 at 9:49 PM, Andrew Ruder wrote: > This mirrors the conventions used in other SPI drivers (kirkwood, > davinci, atmel, et al) where the din/dout buffer can be NULL when the > received/transmitted data isn't important. This reduces the need for > allocating additional buffers w

Re: [U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers

2014-04-10 Thread Andrew Ruder
I further justify this with a list of drivers that depend on half-duplex SPI operation: drivers/mmc/mmc_spi.c: spi_xfer(spi, 2 * 8, tok, NULL, 0); drivers/mtd/spi/eeprom_m95xxx.c:if (spi_xfer(slave, 8, buf, NULL, SPI_XFER_BEGIN | SPI_XFER_END)) drivers/mtd/spi/sf_ops.c:

[U-Boot] [PATCH RESEND-WITH-JUSTIFICATION] spi: soft_spi: Support NULL din/dout buffers

2014-04-10 Thread Andrew Ruder
This mirrors the conventions used in other SPI drivers (kirkwood, davinci, atmel, et al) where the din/dout buffer can be NULL when the received/transmitted data isn't important. This reduces the need for allocating additional buffers when write-only/read-only functionality is needed. In the din