user/sven/linux.git/drivers/spi, branch v3.2.97

spi: fix parent-device reference leak

2016-01-22T21:40:05Z

commit 157f38f993919b648187ba341bfb05d0e91ad2f6 upstream. Fix parent-device reference leak due to SPI-core taking an unnecessary reference to the parent when allocating the master structure, a reference that was never released. Note that driver core takes its own reference to the parent when the master device is registered. Fixes: 49dce689ad4e ("spi doesn't need class_device") Signed-off-by: Johan Hovold Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings

spi: spi-pxa2xx: Check status register to determine if SSSR_TINT is disabled

2015-10-13T02:46:07Z

commit 02bc933ebb59208f42c2e6305b2c17fd306f695d upstream. On Intel Baytrail, there is case when interrupt handler get called, no SPI message is captured. The RX FIFO is indeed empty when RX timeout pending interrupt (SSSR_TINT) happens. Use the BIOS version where both HSUART and SPI are on the same IRQ. Both drivers are using IRQF_SHARED when calling the request_irq function. When running two separate and independent SPI and HSUART application that generate data traffic on both components, user will see messages like below on the console: pxa2xx-spi pxa2xx-spi.0: bad message state in interrupt handler This commit will fix this by first checking Receiver Time-out Interrupt, if it is disabled, ignore the request and return without servicing. Signed-off-by: Tan, Jui Nee Acked-by: Jarkko Nikula Signed-off-by: Mark Brown Signed-off-by: Ben Hutchings

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

2015-05-09T22:16:40Z

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: Ben Hutchings

spi: dw: revisit FIFO size detection again

2015-05-09T22:16:25Z

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 [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

spi: dw-mid: fix FIFO size

2015-02-20T00:49:33Z

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: Ben Hutchings

spi: dw: Fix detecting FIFO depth

2015-02-20T00:49:33Z

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 [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

spi: dw: Fix dynamic speed change.

2014-12-14T16:23:55Z

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: Ben Hutchings

spi: pl022: Fix incorrect dma_unmap_sg

2014-12-14T16:23:48Z

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: Ben Hutchings

spi: dw-mid: terminate ongoing transfers at exit

2014-12-14T16:23:44Z

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 Signed-off-by: Ben Hutchings

spi: dw-mid: check that DMA was inited before exit

2014-12-14T16:23:44Z

commit 63d84b1a46957b3ecc56af8087220c0df42e0ef2 upstream. commit fb57862ead652454ceeb659617404c5f13bc34b5 upstream. If the driver was compiled with DMA support, but DMA channels weren't acquired by some reason, mid_spi_dma_exit() will crash the kernel. Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support) Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings