On Fri, Apr 11, 2014 at 12:47 AM, Andrew Ruder a...@aeruder.net 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 -
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
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:
On Thu, Apr 10, 2014 at 9:49 PM, Andrew Ruder
andrew.ru...@elecsyscorp.com 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
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,
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 drivers.
6 matches
Mail list logo
