linux-stable.git/drivers/spi, branch v3.4.110

spi: spidev: fix possible arithmetic overflow for multi-transfer message

2015-06-19T03:40:32+00:00

commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 upstream.

`spidev_message()` sums the lengths of the individual SPI transfers to
determine the overall SPI message length.  It restricts the total
length, returning an error if too long, but it does not check for
arithmetic overflow.  For example, if the SPI message consisted of two
transfers and the first has a length of 10 and the second has a length
of (__u32)(-1), the total length would be seen as 9, even though the
second transfer is actually very long.  If the second transfer specifies
a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could
overrun the spidev's pre-allocated tx buffer before it reaches an
invalid user memory address.  Fix it by checking that neither the total
nor the individual transfer lengths exceed the maximum allowed value.

Thanks to Dan Carpenter for reporting the potential integer overflow.

Signed-off-by: Ian Abbott 
Signed-off-by: Mark Brown 
[Ian Abbott: Note: original commit compares the lengths to INT_MAX instead
of bufsiz due to changes in earlier commits.]
Signed-off-by: Zefan Li

spi: dw: revisit FIFO size detection again

2015-04-14T09:34:04+00:00

commit 9d239d353c319f9ff884c287ce47feb7cdf60ddc upstream.

The commit d297933cc7fc (spi: dw: Fix detecting FIFO depth) tries to fix the
logic of the FIFO detection based on the description on the comments. However,
there is a slight difference between numbers in TX Level and TX FIFO size.

So, by specification the FIFO size would be in a range 2-256 bytes. From TX
Level prospective it means we can set threshold in the range 0-(FIFO size - 1)
bytes. Hence there are currently two issues:
  a) FIFO size 2 bytes is actually skipped since TX Level is 1 bit and could be
     either 0 or 1 byte;
  b) FIFO size is incorrectly decreased by 1 which already done by meaning of
     TX Level register.

This patch fixes it eventually right.

Fixes: d297933cc7fc (spi: dw: Fix detecting FIFO depth)
Reviewed-by: Axel Lin 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Mark Brown 
Signed-off-by: Zefan Li

spi: dw-mid: fix FIFO size

2015-04-14T09:33:55+00:00

commit 67bf9cda4b498b8cea4a40be67a470afe57d2e88 upstream.

The FIFO size is 40 accordingly to the specifications, but this means 0x40,
i.e. 64 bytes. This patch fixes the typo and enables FIFO size autodetection
for Intel MID devices.

Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support)
Signed-off-by: Andy Shevchenko 
Signed-off-by: Mark Brown 
Signed-off-by: Zefan Li

spi: dw: Fix detecting FIFO depth

2015-04-14T09:33:55+00:00

commit d297933cc7fcfbaaf2d37570baac73287bf0357d upstream.

Current code tries to find the highest valid fifo depth by checking the value
it wrote to DW_SPI_TXFLTR. There are a few problems in current code:
1) There is an off-by-one in dws->fifo_len setting because it assumes the latest
   register write fails so the latest valid value should be fifo - 1.
2) We know the depth could be from 2 to 256 from HW spec, so it is not necessary
   to test fifo == 257. In the case fifo is 257, it means the latest valid
   setting is fifo = 256. So after the for loop iteration, we should check
   fifo == 2 case instead of fifo == 257 if detecting the FIFO depth fails.
This patch fixes above issues.

Signed-off-by: Axel Lin 
Reviewed-and-tested-by: Andy Shevchenko 
Signed-off-by: Mark Brown 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

spi: dw: Fix dynamic speed change.

2015-04-14T09:33:35+00:00

commit 0a8727e69778683495058852f783eeda141a754e upstream.

An IOCTL call that calls spi_setup() and then dw_spi_setup() will
overwrite the persisted last transfer speed. On each transfer, the
SPI speed is compared to the last transfer speed to determine if the
clock divider registers need to be updated (did the speed change?).
This bug was observed with the spidev driver using spi-config to
update the max transfer speed.

This fix: Don't overwrite the persisted last transaction clock speed
when updating the SPI parameters in dw_spi_setup(). On the next
transaction, the new speed won't match the persisted last speed
and the hardware registers will be updated.
On initialization, the persisted last transaction clock
speed will be 0 but will be updated after the first SPI
transaction.

Move zeroed clock divider check into clock change test because
chip->clk_div is zero on startup and would cause a divide-by-zero
error. The calculation was wrong as well (can't support odd #).

Reported-by: Vlastimil Setka 
Signed-off-by: Vlastimil Setka 
Signed-off-by: Thor Thayer 
Signed-off-by: Mark Brown 
Signed-off-by: Zefan Li

spi: pl022: Fix incorrect dma_unmap_sg

2015-02-02T09:05:00+00:00

commit 3ffa6158f002e096d28ede71be4e0ee8ab20baa2 upstream.

When mapped RX DMA entries are unmapped in an error condition when DMA
is firstly configured in the driver, the number of TX DMA entries was
passed in, which is incorrect

Signed-off-by: Ray Jui 
Signed-off-by: Mark Brown 
Signed-off-by: Zefan Li

spi: dw-mid: terminate ongoing transfers at exit

2015-02-02T09:04:41+00:00

commit 8e45ef682cb31fda62ed4eeede5d9745a0a1b1e2 upstream.

Do full clean up at exit, means terminate all ongoing DMA transfers.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Mark Brown 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

spi: dw-mid: respect 8 bit mode

2015-02-02T09:04:41+00:00

commit b41583e7299046abdc578c33f25ed83ee95b9b31 upstream.

In case of 8 bit mode and DMA usage we end up with every second byte written as
0. We have to respect bits_per_word settings what this patch actually does.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Mark Brown 
Signed-off-by: Zefan Li

spi: Fix crash with double message finalisation on error handling

2014-02-22T18:32:45+00:00

commit 1f802f8249a0da536877842c43c7204064c4de8b upstream.

This reverts commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d.

It causes a NULL pointer dereference with drivers using the generic
spi_transfer_one_message(), which always calls
spi_finalize_current_message(), which zeroes master->cur_msg.

Drivers implementing transfer_one_message() theirselves must always call
spi_finalize_current_message(), even if the transfer failed:

 * @transfer_one_message: the subsystem calls the driver to transfer a single
 *      message while queuing transfers that arrive in the meantime. When the
 *      driver is finished with this message, it must call
 *      spi_finalize_current_message() so the subsystem can issue the next
 *      transfer

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spidev: fix hang when transfer_one_message fails

2014-02-13T19:51:12+00:00

commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d upstream.

This corrects a problem in spi_pump_messages() that leads to an spi
message hanging forever when a call to transfer_one_message() fails.
This failure occurs in my MCP2210 driver when the cs_change bit is set
on the last transfer in a message, an operation which the hardware does
not support.

Rationale
Since the transfer_one_message() returns an int, we must presume that it
may fail.  If transfer_one_message() should never fail, it should return
void.  Thus, calls to transfer_one_message() should properly manage a
failure.

Fixes: ffbbdd21329f3 (spi: create a message queueing infrastructure)
Signed-off-by: Daniel Santos 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman