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

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

spi: pl022: Fix race in giveback() leading to driver lock-up

2015-03-28T13:49:32+00:00

[ Upstream commit cd6fa8d2ca53cac3226fdcffcf763be390abae32 ]

Commit fd316941c ("spi/pl022: disable port when unused") introduced a race,
which leads to possible driver lock up (easily reproducible on SMP).

The problem happens in giveback() function where the completion of the transfer
is signalled to SPI subsystem and then the HW SPI controller is disabled. Another
transfer might be setup in between, which brings driver in locked-up state.

Exact event sequence on SMP:

core0                                   core1

                                        => pump_transfers()
                                        /* message->state == STATE_DONE */
                                          => giveback()
                                            => spi_finalize_current_message()

=> pl022_unprepare_transfer_hardware()
=> pl022_transfer_one_message
  => flush()
  => do_interrupt_dma_transfer()
    => set_up_next_transfer()
    /* Enable SSP, turn on interrupts */
    writew((readw(SSP_CR1(pl022->virtbase)) |
           SSP_CR1_MASK_SSE), SSP_CR1(pl022->virtbase));

...

=> pl022_interrupt_handler()
  => readwriter()

                                        /* disable the SPI/SSP operation */
                                        => writew((readw(SSP_CR1(pl022->virtbase)) &
                                                  (~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase));

Lockup! SPI controller is disabled and the data will never be received. Whole
SPI subsystem is waiting for transfer ACK and blocked.

So, only signal transfer completion after disabling the controller.

Fixes: fd316941c (spi/pl022: disable port when unused)
Signed-off-by: Alexander Sverdlin 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

spi: dw-mid: avoid potential NULL dereference

2015-03-28T13:49:22+00:00

[ Upstream commit c9dafb27c84412fe4b17c3b94cc4ffeef5df1833 ]

When DMA descriptor allocation fails we should not try to assign any fields in
the bad descriptor. The patch adds the necessary checks for that.

Fixes: 7063c0d942a1 (spi/dw_spi: add DMA support)
Signed-off-by: Andy Shevchenko 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

spi: atmel: Fix interrupt setup for PDC transfers

2015-03-28T13:44:58+00:00

[ Upstream commit 76e1d14b316d6f501ebc001e7a5d86b24ce5b615 ]

Additionally to the current DMA transfer the PDC allows to set up a next DMA
transfer. This is useful for larger SPI transfers.

The driver currently waits for ENDRX as end of the transfer. But ENDRX is set
when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the
next DMA transfer.
Thus a subsequent SPI transfer could be started although there is currently a
transfer in progress. This can cause invalid accesses to the SPI slave devices
and to SPI transfer errors.

This issue has been observed on a hardware with a M25P128 SPI NOR flash.

So instead of ENDRX we should wait for RXBUFF. This flag is set if there is
no more DMA transfer in progress (RCR = RNCR = 0).

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