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

spi: bitbang: Fix NULL pointer dereference in spi_unregister_master

2019-10-05T15:19:36+00:00

commit 5caaf29af5ca82d5da8bc1d0ad07d9e664ccf1d8 upstream.

If spi_register_master fails in spi_bitbang_start
because device_add failure, We should return the
error code other than 0, otherwise calling
spi_bitbang_stop may trigger NULL pointer dereference
like this:

BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
Read of size 8 at addr 0000000000000000 by task syz-executor.0/3661

CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
 dump_stack+0xa9/0x10e
 ? __list_del_entry_valid+0x45/0xd0
 ? __list_del_entry_valid+0x45/0xd0
 __kasan_report+0x171/0x18d
 ? __list_del_entry_valid+0x45/0xd0
 kasan_report+0xe/0x20
 __list_del_entry_valid+0x45/0xd0
 spi_unregister_controller+0x99/0x1b0
 spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
 ? 0xffffffffc1128000
 ? klist_next+0x131/0x1e0
 ? driver_detach+0x40/0x40 [parport]
 port_check+0x3b/0x50 [parport]
 bus_for_each_dev+0x115/0x180
 ? subsys_dev_iter_exit+0x20/0x20
 __parport_register_driver+0x1f0/0x210 [parport]
 ? 0xffffffffc1150000
 do_one_initcall+0xb9/0x3b5
 ? perf_trace_initcall_level+0x270/0x270
 ? kasan_unpoison_shadow+0x30/0x40
 ? kasan_unpoison_shadow+0x30/0x40
 do_init_module+0xe0/0x330
 load_module+0x38eb/0x4270
 ? module_frob_arch_sections+0x20/0x20
 ? kernel_read_file+0x188/0x3f0
 ? find_held_lock+0x6d/0xd0
 ? fput_many+0x1a/0xe0
 ? __do_sys_finit_module+0x162/0x190
 __do_sys_finit_module+0x162/0x190
 ? __ia32_sys_init_module+0x40/0x40
 ? __mutex_unlock_slowpath+0xb4/0x3f0
 ? wait_for_completion+0x240/0x240
 ? vfs_write+0x160/0x2a0
 ? lockdep_hardirqs_off+0xb5/0x100
 ? mark_held_locks+0x1a/0x90
 ? do_syscall_64+0x14/0x2a0
 do_syscall_64+0x72/0x2a0
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Reported-by: Hulk Robot 
Fixes: 702a4879ec33 ("spi: bitbang: Let spi_bitbang_start() take a reference to master")
Signed-off-by: YueHaibing 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Axel Lin 
Reviewed-by: Mukesh Ojha 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

spi: rspi: Fix sequencer reset during initialization

2019-09-23T20:11:32+00:00

commit 26843bb128590edd7eba1ad7ce22e4b9f1066ce3 upstream.

While the sequencer is reset after each SPI message since commit
880c6d114fd79a69 ("spi: rspi: Add support for Quad and Dual SPI
Transfers on QSPI"), it was never reset for the first message, thus
relying on reset state or bootloader settings.

Fix this by initializing it explicitly during configuration.

Fixes: 0b2182ddac4b8837 ("spi: add support for Renesas RSPI")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

spi: rspi: Fix register initialization while runtime-suspended

2019-09-23T20:11:31+00:00

commit 42bdaaece121b3bb50fd4d1203d6d0170279f9fa upstream.

The Renesas RSPI/QSPI driver performs SPI controller register
initialization in its spi_operations.setup() callback, without calling
pm_runtime_get_sync() first, which may cause spurious failures.

So far this went unnoticed, as this SPI controller is typically used
with a single SPI NOR FLASH containing the boot loader:
1. If the device's module clock is still enabled (left enabled by the
bootloader, and not yet disabled by the clk_disable_unused() late
initcall), register initialization succeeds,
2. If the device's module clock is disabled, register writes don't
seem to cause lock-ups or crashes.
Data received in the first SPI message may be corrupted, though.
Subsequent SPI messages seem to be OK.
E.g. on r8a7791/koelsch, one bit is lost while receiving the 6th
byte of the JEDEC ID for the s25fl512s FLASH, corrupting that byte
and all later bytes. But until commit a2126b0a010905e5 ("mtd:
spi-nor: refine Spansion S25FL512S ID"), the 6th byte was not
considered for FLASH identification.

Fix this by moving all initialization from the .setup() to the
.prepare_message() callback. The latter is always called after the
device has been runtime-resumed by the SPI core.

This also makes the driver follow the rule that .setup() must not change
global driver state or register values, as that might break a transfer
in progress.

Fixes: 490c97747d5dc77d ("spi: rspi: Add runtime PM support, using spi core auto_runtime_pm")
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Mark Brown
[bwh: Backported to 3.16: s/(controller|ctlr)/master/g]
Signed-off-by: Ben Hutchings

spi: omap-100k: Remove unused definitions

2019-05-11T14:22:47+00:00

commit 9f5b8b4f56dd194fd33021810636879036d2acdd upstream.

Remove unused definition which cause the following warnings

drivers/spi/spi-omap-100k.c:73:0: warning: "WRITE" redefined [enabled by default]
include/linux/fs.h:193:0: note: this is the location of the previous definition
drivers/spi/spi-omap-100k.c:74:0: warning: "READ" redefined [enabled by default]
include/linux/fs.h:192:0: note: this is the location of the previous definition

Signed-off-by: Nick Krause 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

spi: sh-msiof: fix deferred probing

2019-02-11T17:53:32+00:00

commit f34c6e6257aa477cdfe7e9bbbecd3c5648ecda69 upstream.

Since commit 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
platform_get_irq() can return -EPROBE_DEFER. However, the driver overrides
an error returned by that function with -ENOENT which breaks the deferred
probing. Propagate upstream an error code returned by platform_get_irq()
and remove the bogus "platform" from the error message, while at it...

Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

spi: rspi: Fix interrupted DMA transfers

2018-12-16T22:09:07+00:00

commit 8dbbaa47b96f6ea5f09f922b4effff3c505cd8cf upstream.

When interrupted, wait_event_interruptible_timeout() returns
-ERESTARTSYS, and the SPI transfer in progress will fail, as expected:

    m25p80 spi0.0: SPI transfer failed: -512
    spi_master spi0: failed to transfer one message from queue

However, as the underlying DMA transfers may not have completed, all
subsequent SPI transfers may start to fail:

    spi_master spi0: receive timeout
    qspi_transfer_out_in() returned -110
    m25p80 spi0.0: SPI transfer failed: -110
    spi_master spi0: failed to transfer one message from queue

Fix this by calling dmaengine_terminate_all() not only for timeouts, but
also for errors.

This can be reproduced on r8a7991/koelsch, using "hd /dev/mtd0" followed
by CTRL-C.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

spi: rspi: Fix leaking of unused DMA descriptors

2018-12-16T22:09:07+00:00

commit 3819bc8752367eae0d72fa1c473dc88ea45631a7 upstream.

If dmaengine_prep_slave_sg() or dmaengine_submit() fail, we may leak
unused DMA descriptors.

As per Documentation/dmaengine.txt, once a DMA descriptor has been
obtained, it must be submitted. Hence:
  - First prepare and submit all DMA descriptors,
  - Prepare the SPI controller for DMA,
  - Start DMA by calling dma_async_issue_pending(),
  - Make sure to call dmaengine_terminate_all() on all descriptors that
    haven't completed.

Reported-by: Laurent Pinchart 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

spi: rspi: Handle dmaengine_prep_slave_sg() failures gracefully

2018-12-16T22:09:06+00:00

commit 85912a88c1ebcad04a5cfec971771195ce8d6691 upstream.

As typically a shmobile SoC has less DMA channels than devices that can use
DMA, we may want to prioritize access to the DMA channels in the future.
This means that dmaengine_prep_slave_sg() may start failing arbitrarily.

Handle dmaengine_prep_slave_sg() failures gracefully by falling back to
PIO.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Laurent Pinchart 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

spi: rspi: Fix invalid SPI use during system suspend

2018-12-16T22:09:06+00:00

commit c1ca59c22c56930b377a665fdd1b43351887830b upstream.

If the SPI queue is running during system suspend, the system may lock
up.

Fix this by stopping/restarting the queue during system suspend/resume,
by calling spi_master_suspend()/spi_master_resume() from the PM
callbacks.  In-kernel users will receive an -ESHUTDOWN error while
system suspend/resume is in progress.

Based on a patch for sh-msiof by Gaku Inami.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

spi: sh-msiof: Fix handling of write value for SISTR register

2018-12-16T22:09:06+00:00

commit 31a5fae4c5a009898da6d177901d5328051641ff upstream.

This patch changes writing to the SISTR register according to the H/W
user's manual.

The TDREQ bit and RDREQ bits of SISTR are read-only, and must be written
their initial values of zero.

Signed-off-by: Hiromitsu Yamasaki 
[geert: reword]
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings