[PATCH] SPI: define null tx_buf to mean "shift out zeroes"

Some issues were recently turned up with the current specification of what
it means for spi_transfer.tx_buf to be null, as part of transfers which are
(from the SPI protocol driver perspective) pure reads.

Specifically, that it seems better to change the TX behaviour there from
"undefined" to "will shift zeroes".  This lets protocol drivers (like the
ads7846 driver) depend on that behavior.  It's what most controller drivers
in the tree are already doing (with one exception and one case of driver
wanting-to-oops), it's what Microwire hardware will necessarily be doing,
and it removes an issue whereby certain security audits would need to
define such a value anyway as part of removing covert channels.

This patch changes the specification to require shifting zeroes, and
updates all currently merged SPI controller drivers to do so.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

1 files changed, 2 insertions, 0 deletions

diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index ff0b04895db0..e9798bf7b8c6 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -112,6 +112,8 @@ u32 mpc83xx_spi_tx_buf_##type(struct mpc83xx_spi *mpc83xx_spi)	\
 {                                                               \
         u32 data;                                               \
         const type * tx = mpc83xx_spi->tx;                      \
+        if (!tx)                                                \
+                return 0;                                       \
         data = *tx++;                                           \
         mpc83xx_spi->tx = tx;                                   \
         return data;                                            \