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

spi: fix parent-device reference leak

2016-01-25T10:43:39+00:00

commit 157f38f993919b648187ba341bfb05d0e91ad2f6 upstream.

Fix parent-device reference leak due to SPI-core taking an unnecessary
reference to the parent when allocating the master structure, a
reference that was never released.

Note that driver core takes its own reference to the parent when the
master device is registered.

Fixes: 49dce689ad4e ("spi doesn't need class_device")
Signed-off-by: Johan Hovold 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques

spi: atmel: Fix DMA-setup for transfers with more than 8 bits per word

2015-12-13T17:48:53+00:00

commit 06515f83908d038d9e12ffa3dcca27a1b67f2de0 upstream.

The DMA-slave configuration depends on the whether <= 8 or > 8 bits
are transferred per word, so we need to call
atmel_spi_dma_slave_config() with the correct value.

Signed-off-by: David Mosberger 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques

spi: dw: explicitly free IRQ handler in dw_spi_remove_host()

2015-12-13T17:48:49+00:00

commit 02f20387e1bca550639c37b1945f20cd32ddfcce upstream.

The following warning occurs when DW SPI is compiled as a module and it's a PCI
device. On the removal stage pcibios_free_irq() is called earlier than
free_irq() due to the latter is called at managed resources free strage.

------------[ cut here ]------------
WARNING: CPU: 1 PID: 1003 at /home/andy/prj/linux/fs/proc/generic.c:575 remove_proc_entry+0x118/0x150()
remove_proc_entry: removing non-empty directory 'irq/38', leaking at least 'dw_spi1'
Modules linked in: spi_dw_midpci(-) spi_dw [last unloaded: dw_dmac_core]
CPU: 1 PID: 1003 Comm: modprobe Not tainted 4.3.0-rc5-next-20151013+ #32
 00000000 00000000 f5535d70 c12dc220 f5535db0 f5535da0 c104e912 c198a6bc
 f5535dcc 000003eb c198a638 0000023f c11b4098 c11b4098 f54f1ec8 f54f1ea0
 f642ba20 f5535db8 c104e96e 00000009 f5535db0 c198a6bc f5535dcc f5535df0
Call Trace:
 [] dump_stack+0x41/0x61
 [] warn_slowpath_common+0x82/0xb0
 [] ? remove_proc_entry+0x118/0x150
 [] ? remove_proc_entry+0x118/0x150
 [] warn_slowpath_fmt+0x2e/0x30
 [] remove_proc_entry+0x118/0x150
 [] unregister_irq_proc+0xaa/0xc0
 [] free_desc+0x1e/0x60
 [] irq_free_descs+0x32/0x70
 [] irq_domain_free_irqs+0x120/0x150
 [] mp_unmap_irq+0x5c/0x60
 [] intel_mid_pci_irq_disable+0x20/0x40
 [] pcibios_free_irq+0xf/0x20
 [] pci_device_remove+0x52/0xb0
 [] __device_release_driver+0x77/0x100
 [] driver_detach+0x87/0x90
 [] bus_remove_driver+0x4a/0xc0
 [] ? selinux_capable+0xd/0x10
 [] driver_unregister+0x23/0x60
 [] ? find_module_all+0x5a/0x80
 [] pci_unregister_driver+0x13/0x60
 [] dw_spi_driver_exit+0xd/0xf [spi_dw_midpci]
 [] SyS_delete_module+0x17a/0x210

Explicitly call free_irq() at removal stage of the DW SPI driver.

Fixes: 04f421e7b0b1 (spi: dw: use managed resources)
Signed-off-by: Andy Shevchenko 
Signed-off-by: Mark Brown 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

spi: ti-qspi: Fix data corruption seen on r/w stress test

2015-12-13T17:48:43+00:00

commit bc27a53928981662079aa243915b443370294a03 upstream.

Writing invalid command to QSPI_SPI_CMD_REG will terminate current
transfer and de-assert the chip select. This has to be done before
calling spi_finalize_current_message(). Because
spi_finalize_current_message() will mark the end of current message
transfer and schedule the next transfer. If the chipselect is not
de-asserted before calling spi_finalize_current_message() then the next
transfer will overlap with the previous transfer leading to data
corruption.
__spi_pump_message() can be called either from kthread worker context or
directly from the calling process's context. It is possible that these
two calls can race against each other. But race is serialized by
checking whether master->cur_msg == NULL (pointer to msg being handled
by transfer_one() at present). The master->cur_msg is set to NULL when
spi_finalize_current_message() is called on that message, which means
calling spi_finalize_current_message() allows __spi_sync() to pump next
message in calling process context.
Now if spi-ti-qspi calls spi_finalize_current_message() before we
terminate transfer at hardware side, if __spi_pump_message() is called
from process context then the successive transactions can overlap.

Fix this by moving writing invalid command to QSPI_SPI_CMD_REG to
before calling spi_finalize_current_message() call.

Signed-off-by: Vignesh R 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques

spi: xtensa-xtfpga: fix register endianness

2015-10-19T09:54:29+00:00

commit b0b4855099e301c8603ea37da9a0103a96c2e0b1 upstream.

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 
Signed-off-by: Luis Henriques

spi: Fix documentation of spi_alloc_master()

2015-10-09T13:41:03+00:00

commit a394d635193b641f2c86ead5ada5b115d57c51f8 upstream.

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 
Signed-off-by: Luis Henriques

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

2015-10-09T13:41:03+00:00

commit 02bc933ebb59208f42c2e6305b2c17fd306f695d upstream.

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 
Signed-off-by: Luis Henriques

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

2015-07-09T13:35:59+00:00

commit 8e76ef88f607174082023f50b87fe12dcdbe5db5 upstream.

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 
Signed-off-by: Luis Henriques

spi: bitbang: Make setup_transfer() callback optional

2015-05-28T09:00:04+00:00

commit 7d0ec8b6f40b356f780b79de63eeafd6b907d68c upstream.

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: Luis Henriques

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

2015-04-27T08:48:12+00:00

commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 upstream.

`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 
[ luis: backported to 3.16: used backport provided by Ian ]
Signed-off-by: Luis Henriques