linux-toradex.git/drivers/spi, branch v3.18.13

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

spi: imx: use pio mode for i.mx6dl

2015-02-11T07:00:51+00:00

commit a02bb401f8ae264be782ee57d98bdd99f14c8022 upstream.

For TKT238285 hardware issue which may cause txfifo store data twice can only
be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.

Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support)
Signed-off-by: Robin Gong 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: spi-fsl-dspi: Remove usage of devm_kzalloc

2015-02-11T07:00:50+00:00

commit 973fbce69ed8e79b5fe3ad19cfecb581a7ef8048 upstream.

devm_* API was supposed to be used only in probe function call.
Memory is allocated at 'probe' and free automatically at 'remove'.
Usage of devm_* functions outside probe sometimes leads to memory leak.
Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead.
Also add the dspi_cleanup function to free the controller data upon
cleanup.

Acked-by: Stefan Agner 
Signed-off-by: Bhuvanchandra DV 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi/pxa2xx: Clear cur_chip pointer before starting next message

2015-02-06T06:36:07+00:00

commit c957e8f084e0d21febcd6b8a0ea9631eccc92f36 upstream.

Once the current message is finished, the driver notifies SPI core about
this by calling spi_finalize_current_message(). This function queues next
message to be transferred. If there are more messages in the queue, it is
possible that the driver is asked to transfer the next message at this
point.

When spi_finalize_current_message() returns the driver clears the
drv_data->cur_chip pointer to NULL. The problem is that if the driver
already started the next message clearing drv_data->cur_chip will cause
NULL pointer dereference which crashes the kernel like:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
 IP: [] cs_deassert+0x18/0x70 [spi_pxa2xx_platform]
 PGD 78bb8067 PUD 37712067 PMD 0
 Oops: 0000 [#1] SMP
 Modules linked in:
 CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G           O   3.18.0-rc4-mjo #5
 Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014
 task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000
 RIP: 0010:[]  [] cs_deassert+0x18/0x70 [spi_pxa2xx_platform]
 RSP: 0018:ffff88007a823d08  EFLAGS: 00010202
 RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026
 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430
 RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a
 R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98
 R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000
 FS:  0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0
 Stack:
  ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89
  0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006
  ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204
 Call Trace:
  [] giveback+0x69/0xa0 [spi_pxa2xx_platform]
  [] pump_transfers+0x710/0x740 [spi_pxa2xx_platform]
  [] ? pick_next_task_fair+0x744/0x830
  [] tasklet_action+0xa9/0xe0
  [] __do_softirq+0xee/0x280
  [] run_ksoftirqd+0x20/0x40
  [] smpboot_thread_fn+0xff/0x1b0
  [] ? SyS_setgroups+0x150/0x150
  [] kthread+0xcd/0xf0
  [] ? kthread_create_on_node+0x180/0x180
  [] ret_from_fork+0x7c/0xb0

Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message().

Reported-by: Martin Oldfield 
Signed-off-by: Mika Westerberg 
Acked-by: Robert Jarzmik 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: dw-mid: fix FIFO size

2015-02-06T06:36:01+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: Greg Kroah-Hartman

spi: dw: Fix detecting FIFO depth

2015-02-06T06:36:00+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 
Signed-off-by: Greg Kroah-Hartman