Lines Matching +full:wr +full:- +full:active
5 SPI devices have a limited userspace API, supporting basic half-duplex
19 * Prototyping in an environment that's not crash-prone; stray pointers
38 - struct spi_device_id spidev_spi_ids[]: list of devices that can be
42 - struct of_device_id spidev_dt_ids[]: list of devices that can be
46 - struct acpi_device_id spidev_acpi_ids[]: list of devices that can
52 post a patch for spidev to the linux-spi@vger.kernel.org mailing list.
101 Since this is a standard Linux device driver -- even though it just happens
102 to expose a low level API to userspace -- it can be associated with any number
112 Standard read() and write() operations are obviously only half-duplex, and
113 the chipselect is deactivated between those operations. Full-duplex access,
114 and composite operation without chipselect de-activation, is available using
122 return (RD) or assign (WR) the SPI transfer mode. Use the constants
131 which will return (RD) or assign (WR) the full SPI transfer mode,
136 which will return (RD) or assign (WR) the bit justification used to
137 transfer SPI words. Zero indicates MSB-first; other values indicate
138 the less common LSB-first encoding. In both cases the specified value
139 is right-justified in each word, so that unused (TX) or undefined (RX)
144 a byte which will return (RD) or assign (WR) the number of bits in
149 u32 which will return (RD) or assign (WR) the maximum SPI transfer
155 - At this time there is no async I/O support; everything is purely
158 - There's currently no way to report the actual bit rate used to
161 - From userspace, you can't currently change the chip select polarity;
163 Each SPI device is deselected when it's not in active use, allowing
166 - There's a limit on the number of bytes each I/O request can transfer
170 - Because SPI has no low-level transfer acknowledgement, you usually
171 won't see any I/O errors when talking to a non-existent device.
183 The example shows one half-duplex RPC-style request and response message.