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

spi: spi-ath79: fix initial GPIO CS line setup

2014-03-24T04:38:16+00:00

commit 61d1cf163c8653934cc8cd5d0b2a562d0990c265 upstream.

The 'ath79_spi_setup_cs' function initializes the chip
select line of a given SPI device in order to make sure
that the device is inactive.

If the SPI_CS_HIGH bit is set for a given device, it
means that the CS line of that device is active HIGH
so it must be set to LOW initially. In case of GPIO
CS lines, the 'ath79_spi_setup_cs' function does the
opposite of that due to the wrong GPIO flags.

Fix the code to use the correct GPIO flags.

Reported-by: Ronald Wahl 
Signed-off-by: Gabor Juhos 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: Fix crash with double message finalisation on error handling

2014-02-22T20:41:26+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-13T21:48:01+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

spi/bcm63xx: don't substract prepend length from total length

2014-02-13T21:48:01+00:00

commit 86b3bde003e6bf60ccb9c09b4115b8a2f533974c upstream.

The spi command must include the full message length including any
prepended writes, else transfers larger than 256 bytes will be
incomplete.

Signed-off-by: Jonas Gorski 
Acked-by: Florian Fainelli 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: spi-davinci: Fix direction in dma_map_single()

2013-08-12T01:35:25+00:00

commit 89c66ee890af18500fa4598db300cc07c267f900 upstream.

Commit 048177ce3b3962852fd34a7e04938959271c7e70 (spi: spi-davinci:
convert to DMA engine API) introduced a regression: dma_map_single()
is called with direction DMA_FROM_DEVICE for rx and for tx.

Signed-off-by: Christian Eggers 
Acked-by: Matt Porter 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branch 'spi/fix/s3c64xx' into spi-linus

2013-06-24T11:28:29+00:00

spi/pxa2xx: fix memory corruption due to wrong size used in devm_kzalloc()

2013-06-21T09:53:37+00:00

ACPI part of the driver accidentally used sizeof(*ssp) instead of the
correct sizeof(*pdata). This leads to nasty memory corruptions like the one
below:

    BUG: unable to handle kernel paging request at 0000000749fd30b8
    IP: [] __list_del_entry+0x31/0xd0
    PGD 0
    Oops: 0000 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.0-rc6v3.10-rc6_sdhci_modprobe+ #443
    task: ffff8801483a0940 ti: ffff88014839e000 task.ti: ffff88014839e000
    RIP: 0010:[]  [] __list_del_entry+0x31/0xd0
    RSP: 0000:ffff88014839fde8  EFLAGS: 00010046
    RAX: ffff880149fd30b0 RBX: ffff880149fd3040 RCX: dead000000200200
    RDX: 0000000749fd30b0 RSI: ffff880149fd3058 RDI: ffff88014834d640
    RBP: ffff88014839fde8 R08: ffff88014834d640 R09: 0000000000000001
    R10: ffff8801483a0940 R11: 0000000000000001 R12: ffff880149fd3040
    R13: ffffffff810e0b30 R14: ffff8801483a0940 R15: ffff88014834d640
    FS:  0000000000000000(0000) GS:ffff880149e00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000168 CR3: 0000000001e0b000 CR4: 00000000001407f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff88014839fe48 ffffffff810e0baf ffffffff81120abd ffff88014839fe20
     ffff8801483a0940 ffff8801483a0940 ffff8801483a0940 ffff8801486b1c90
     ffff88014834d640 ffffffff810e0b30 0000000000000000 0000000000000000
    Call Trace:
     [] worker_thread+0x7f/0x390
     [] ? trace_hardirqs_on+0xd/0x10
     [] ? manage_workers.isra.22+0x2b0/0x2b0
     [] kthread+0xd9/0xe0
     [] ? local_clock+0x3f/0x50
     [] ? kthread_create_on_node+0x110/0x110
     [] ret_from_fork+0x7c/0xb0
     [] ? kthread_create_on_node+0x110/0x110

Fix this by using the right structure size in devm_kzalloc().

Reported-by: Jerome Blin 
Signed-off-by: Mika Westerberg 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org # 3.9+

spi/pxa2xx: use GFP_ATOMIC in sg table allocation

2013-06-18T18:11:04+00:00

pxa2xx_spi_map_dma_buffer() gets called in tasklet context so we can't
sleep when we allocate a new sg table. Use GFP_ATOMIC here instead.

Signed-off-by: Mika Westerberg 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org

spi: s3c64xx: Fix pm_runtime_get_sync() return value check

2013-06-10T17:04:00+00:00

If the device is already in a runtime PM enabled state
pm_runtime_get_sync() will return 1, so a test for negative
value should be used to check for errors.

Without this patch there are seen errors like:

[    8.540000] s3c64xx-spi 13930000.spi: Failed to enable device: 1
[    8.545000] spi_master spi1: failed to prepare transfer hardware

Likely because the driver uses synchronous API to runtime enable
the device and asynchronous one to disable it.

Signed-off-by: Sylwester Nawrocki 
Signed-off-by: Kyungmin Park 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org

Merge remote-tracking branch 'spi/fix/xilinx' into spi-linus

2013-06-04T17:52:05+00:00