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

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

2015-10-28T02:13:18+00:00

[ Upstream commit 02bc933ebb59208f42c2e6305b2c17fd306f695d ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

spi: xtensa-xtfpga: fix register endianness

2015-10-28T02:13:17+00:00

[ Upstream commit b0b4855099e301c8603ea37da9a0103a96c2e0b1 ]

XTFPGA SPI controller has native endian registers.
Fix register acessors so that they work in big-endian configurations.

Signed-off-by: Max Filippov 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

spi: Fix documentation of spi_alloc_master()

2015-10-28T02:13:17+00:00

[ Upstream commit a394d635193b641f2c86ead5ada5b115d57c51f8 ]

Actually, spi_master_put() after spi_alloc_master() must _not_ be followed
by kfree(). The memory is already freed with the call to spi_master_put()
through spi_master_class, which registers a release function. Calling both
spi_master_put() and kfree() results in often nasty (and delayed) crashes
elsewhere in the kernel, often in the networking stack.

This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a.

Link to patch and concerns: https://lkml.org/lkml/2012/9/3/269
or
http://lkml.iu.edu/hypermail/linux/kernel/1209.0/00790.html

Alexey Klimov: This revert becomes valid after
94c69f765f1b4a658d96905ec59928e3e3e07e6a when spi-imx.c
has been fixed and there is no need to call kfree() so comment
for spi_alloc_master() should be fixed.

Signed-off-by: Guenter Roeck 
Signed-off-by: Alexey Klimov 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

spi: orion: Fix maximum baud rates for Armada 370/XP

2015-07-04T03:02:19+00:00

[ Upstream commit ce2f6ea1cbd41d78224f703af980a6ceeb0eb56a ]

The commit df59fa7f4bca "spi: orion: support armada extended baud
rates" was too optimistic for the maximum baud rate that the Armada
SoCs can support. According to the hardware datasheet the maximum
frequency supported by the Armada 370 SoC is tclk/4. But for the
Armada XP, Armada 38x and Armada 39x SoCs the limitation is 50MHz and
for the Armada 375 it is tclk/15.

Currently the armada-370-spi compatible is only used by the Armada 370
and the Armada XP device tree. On Armada 370, tclk cannot be higher
than 200MHz. In order to be able to handle both SoCs, we can take the
minimum of 50MHz and tclk/4.

A proper solution is adding a compatible string for each SoC, but it
can't be done as a fix for compatibility reason (we can't modify
device tree that have been already released) and it will be part of a
separate patch.

Fixes: df59fa7f4bca (spi: orion: support armada extended baud rates)
Reported-by: Kostya Porotchkin 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Mark Brown 
Cc: 
Signed-off-by: Sasha Levin

spi: fix race freeing dummy_tx/rx before it is unmapped

2015-07-04T03:02:14+00:00

[ Upstream commit 8e76ef88f607174082023f50b87fe12dcdbe5db5 ]

Fix a race (with some kernel configurations) where a queued
master->pump_messages runs and frees dummy_tx/rx before
spi_unmap_msg is running (or is finished).

This results in the following messages:
  BUG: Bad page state in process
  page:db7ba030 count:0 mapcount:0 mapping:  (null) index:0x0
  flags: 0x200(arch_1)
  page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
  ...

Reported-by: Noralf Trønnes 
Suggested-by: Noralf Trønnes 
Tested-by: Noralf Trønnes 
Signed-off-by: Martin Sperl 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

spi: bitbang: Make setup_transfer() callback optional

2015-06-28T17:39:27+00:00

[ Upstream commit 7d0ec8b6f40b356f780b79de63eeafd6b907d68c ]

Some controller drivers have no need of this callback (spi-altera even
causes a NULL pointer dereference because it doesn't register the callback,
falsely assuming that it is already optional).

Fixes: 30af9b558a56 ("spi/bitbang: Drop empty setup() functions")
Signed-off-by: Pelle Nilsson 
Reviewed-by: Ezequiel Garcia 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

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

2015-05-17T23:11:54+00:00

[ Upstream commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 ]

`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 
Signed-off-by: Sasha Levin

spi: imx: read back the RX/TX watermark levels earlier

2015-05-17T23:11:54+00:00

[ Upstream commit f511ab09dfb0fe7b2335eccac51ff9f001a32e4a ]

They are used to decide if the controller can do DMA on a buffer
of a specific length and thus are needed before any transfer is attempted.

This fixes a memory leak where the SPI core uses the drivers can_dma()
callback to determine if a buffer needs to be mapped. As the watermark
levels aren't correct at that point the driver falsely claims to be able to
DMA the buffer when it fact it isn't.
After the transfer has been done the core uses the same callback to
determine if it needs to unmap the buffers. As the driver now correctly
claims to not being able to DMA the buffer the core doesn't attempt to
unmap the buffer which leaves the SGT leaking.

Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support)
Signed-off-by: Lucas Stach 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

spi: trigger trace event for message-done before mesg->complete

2015-04-17T00:13:13+00:00

[ Upstream commit 391949b6f02121371e3d7d9082c6d17fd9853034 ]

With spidev the mesg->complete callback points to spidev_complete.
Calling this unblocks spidev_sync and so spidev_sync_write finishes. As
the struct spi_message just read is a local variable in
spidev_sync_write and recording the trace event accesses this message
the recording is better done first. The same can happen for
spidev_sync_read.

This fixes an oops observed on a 3.14-rt system with spidev activity
after

	echo 1 > /sys/kernel/debug/tracing/events/spi/enable

.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

spi: qup: Fix cs-num DT property parsing

2015-04-17T00:13:12+00:00

[ Upstream commit 12cb89e37a0c25fae7a0f1d2e4985558db9d0b13 ]

num-cs is 32 bit property, don't read just upper 16 bits.

Fixes: 4a8573abe965 (spi: qup: Remove chip select function)
Signed-off-by: Ivan T. Ivanov 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin