spi_sync(9) [centos man page]

SPI_SYNC(9)						  Serial Peripheral Interface (S					       SPI_SYNC(9)

NAME

       spi_sync - blocking/synchronous SPI data transfers

SYNOPSIS

       int spi_sync(struct spi_device * spi, struct spi_message * message);

ARGUMENTS

       spi
	   device with which data will be exchanged

       message
	   describes the data transfers

CONTEXT

       can sleep

DESCRIPTION

       This call may only be used from a context that may sleep. The sleep is non-interruptible, and has no timeout. Low-overhead controller
       drivers may DMA directly into and out of the message buffers.

       Note that the SPI device's chip select is active during the message, and then is normally disabled between messages. Drivers for some
       frequently-used devices may want to minimize costs of selecting a chip, by leaving it selected in anticipation that the next message will
       go to the same chip. (That may increase power usage.)

       Also, the caller is guaranteeing that the memory associated with the message will not be freed before this call returns.

       It returns zero on success, else a negative error code.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014							       SPI_SYNC(9)

SPI_ASYNC(9)						  Serial Peripheral Interface (S					      SPI_ASYNC(9)

NAME

       spi_async - asynchronous SPI transfer

SYNOPSIS

       int spi_async(struct spi_device * spi, struct spi_message * message);

ARGUMENTS

       spi
	   device with which data will be exchanged

       message
	   describes the data transfers, including completion callback

CONTEXT

       any (irqs may be blocked, etc)

DESCRIPTION

       This call may be used in_irq and other contexts which can't sleep, as well as from task contexts which can sleep.

       The completion callback is invoked in a context which can't sleep. Before that invocation, the value of message->status is undefined. When
       the callback is issued, message->status holds either zero (to indicate complete success) or a negative error code. After that callback
       returns, the driver which issued the transfer request may deallocate the associated memory; it's no longer in use by any SPI core or
       controller driver code.

       Note that although all messages to a spi_device are handled in FIFO order, messages may go to different devices in other orders. Some
       device might be higher priority, or have various "hard" access time requirements, for example.

       On detection of any fault during the transfer, processing of the entire message is aborted, and the device is deselected. Until returning
       from the associated message completion callback, no other spi_message queued to that device will be processed. (This rule applies equally
       to all the synchronous transfer calls, which are wrappers around this core asynchronous primitive.)

COPYRIGHT

Kernel Hackers Manual 2.6.					     July 2010							      SPI_ASYNC(9)