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

spi: omap2-mcspi: Configure hardware when slave driver changes mode

2014-09-17T16:03:57+00:00

commit 97ca0d6cc118716840ea443e010cb3d5f2d25eaf upstream.

Commit id 2bd16e3e23d9df41592c6b257c59b6860a9cc3ea
(spi: omap2-mcspi: Do not configure the controller
on each transfer unless needed) does its job too
well so omap2_mcspi_setup_transfer() isn't called
even when an SPI slave driver changes 'spi->mode'.
The result is that the mode requested by the SPI
slave driver never takes effect.

Fix this by adding the 'mode' member to the
omap2_mcspi_cs structure which holds the mode
value that the hardware is configured for.
When the SPI slave driver changes 'spi->mode'
it will be different than the value of this new
member and the SPI master driver will know that
the hardware must be reconfigured (by calling
omap2_mcspi_setup_transfer()).

Fixes: 2bd16e3e23 (spi: omap2-mcspi: Do not configure the controller on each transfer unless needed)
Signed-off-by: Mark A. Greer 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: orion: fix incorrect handling of cell-index DT property

2014-09-17T16:03:57+00:00

commit e06871cd2c92e5c65d7ca1d32866b4ca5dd4ac30 upstream.

In commit f814f9ac5a81 ("spi/orion: add device tree binding"), Device
Tree support was added to the spi-orion driver. However, this commit
reads the "cell-index" property, without taking into account the fact
that DT properties are big-endian encoded.

Since most of the platforms using spi-orion with DT have apparently
not used anything but cell-index = <0>, the problem was not
visible. But as soon as one starts using cell-index = <1>, the problem
becomes clearly visible, as the master->bus_num gets a wrong value
(actually it gets the value 0, which conflicts with the first bus that
has cell-index = <0>).

This commit fixes that by using of_property_read_u32() to read the
property value, which does the appropriate endianness conversion when
needed.

Fixes: f814f9ac5a81 ("spi/orion: add device tree binding")
Signed-off-by: Thomas Petazzoni 
Acked-by: Sebastian Hesselbarth 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

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