linux-stable.git/drivers/spi, branch v5.4.285

spi: bcm63xx: Fix module autoloading

2024-11-08T15:20:39+00:00

commit 909f34f2462a99bf876f64c5c61c653213e32fce upstream.

Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
based on the alias from platform_device_id table.

Fixes: 44d8fb30941d ("spi/bcm63xx: move register definitions into the driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jinjie Ruan 
Reviewed-by: Jonas Gorski 
Link: https://patch.msgid.link/20240819123349.4020472-2-ruanjinjie@huawei.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: s3c64xx: fix timeout counters in flush_fifo

2024-11-08T15:20:39+00:00

[ Upstream commit 68a16708d2503b6303d67abd43801e2ca40c208d ]

In the s3c64xx_flush_fifo() code, the loops counter is post-decremented
in the do { } while(test && loops--) condition. This means the loops is
left at the unsigned equivalent of -1 if the loop times out. The test
after will never pass as if tests for loops == 0.

Signed-off-by: Ben Dooks 
Fixes: 230d42d422e7 ("spi: Add s3c64xx SPI Controller driver")
Reviewed-by: Andi Shyti 
Link: https://patch.msgid.link/20240924134009.116247-2-ben.dooks@codethink.co.uk
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ

2024-11-08T15:20:28+00:00

[ Upstream commit 7781f1d120fec8624fc654eda900fc8748262082 ]

0 is incorrect error code when failed to parse and map IRQ.
Replace OF specific old API for IRQ retrieval with a generic
one to fix this issue.

Fixes: 0f245463b01e ("spi: ppc4xx: handle irq_of_parse_and_map() errors")
Signed-off-by: Andy Shevchenko 
Link: https://patch.msgid.link/20240814144525.2648450-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: ppc4xx: handle irq_of_parse_and_map() errors

2024-11-08T15:20:28+00:00

[ Upstream commit 0f245463b01ea254ae90e1d0389e90b0e7d8dc75 ]

Zero and negative number is not a valid IRQ for in-kernel code and the
irq_of_parse_and_map() function returns zero on error.  So this check for
valid IRQs should only accept values > 0.

Fixes: 44dab88e7cc9 ("spi: add spi_ppc4xx driver")
Signed-off-by: Ma Ke 
Link: https://patch.msgid.link/20240724084047.1506084-1-make24@iscas.ac.cn
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: bcm63xx: Enable module autoloading

2024-11-08T15:20:25+00:00

[ Upstream commit 709df70a20e990d262c473ad9899314039e8ec82 ]

Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based
on the alias from of_device_id table.

Signed-off-by: Liao Chen 
Link: https://patch.msgid.link/20240831094231.795024-1-liaochen4@huawei.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: nxp-fspi: fix the KASAN report out-of-bounds bug

2024-11-08T15:20:25+00:00

commit 2a8787c1cdc7be24fdd8953ecd1a8743a1006235 upstream.

Change the memcpy length to fix the out-of-bounds issue when writing the
data that is not 4 byte aligned to TX FIFO.

To reproduce the issue, write 3 bytes data to NOR chip.

dd if=3b of=/dev/mtd0
[   36.926103] ==================================================================
[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838
[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455
[   36.946721]
[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070
[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)
[   36.961260] Call trace:
[   36.963723]  dump_backtrace+0x90/0xe8
[   36.967414]  show_stack+0x18/0x24
[   36.970749]  dump_stack_lvl+0x78/0x90
[   36.974451]  print_report+0x114/0x5cc
[   36.978151]  kasan_report+0xa4/0xf0
[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28
[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838
[   36.990800]  spi_mem_exec_op+0x8ec/0xd30
[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0
[   36.999323]  spi_mem_dirmap_write+0x238/0x32c
[   37.003710]  spi_nor_write_data+0x220/0x374
[   37.007932]  spi_nor_write+0x110/0x2e8
[   37.011711]  mtd_write_oob_std+0x154/0x1f0
[   37.015838]  mtd_write_oob+0x104/0x1d0
[   37.019617]  mtd_write+0xb8/0x12c
[   37.022953]  mtdchar_write+0x224/0x47c
[   37.026732]  vfs_write+0x1e4/0x8c8
[   37.030163]  ksys_write+0xec/0x1d0
[   37.033586]  __arm64_sys_write+0x6c/0x9c
[   37.037539]  invoke_syscall+0x6c/0x258
[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c
[   37.046244]  do_el0_svc+0x44/0x5c
[   37.049589]  el0_svc+0x38/0x78
[   37.052681]  el0t_64_sync_handler+0x13c/0x158
[   37.057077]  el0t_64_sync+0x190/0x194
[   37.060775]
[   37.062274] Allocated by task 455:
[   37.065701]  kasan_save_stack+0x2c/0x54
[   37.069570]  kasan_save_track+0x20/0x3c
[   37.073438]  kasan_save_alloc_info+0x40/0x54
[   37.077736]  __kasan_kmalloc+0xa0/0xb8
[   37.081515]  __kmalloc_noprof+0x158/0x2f8
[   37.085563]  mtd_kmalloc_up_to+0x120/0x154
[   37.089690]  mtdchar_write+0x130/0x47c
[   37.093469]  vfs_write+0x1e4/0x8c8
[   37.096901]  ksys_write+0xec/0x1d0
[   37.100332]  __arm64_sys_write+0x6c/0x9c
[   37.104287]  invoke_syscall+0x6c/0x258
[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c
[   37.112972]  do_el0_svc+0x44/0x5c
[   37.116319]  el0_svc+0x38/0x78
[   37.119401]  el0t_64_sync_handler+0x13c/0x158
[   37.123788]  el0t_64_sync+0x190/0x194
[   37.127474]
[   37.128977] The buggy address belongs to the object at ffff00081037c2a0
[   37.128977]  which belongs to the cache kmalloc-8 of size 8
[   37.141177] The buggy address is located 0 bytes inside of
[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)
[   37.153465]
[   37.154971] The buggy address belongs to the physical page:
[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c
[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)
[   37.175149] page_type: 0xfdffffff(slab)
[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000
[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000
[   37.194553] page dumped because: kasan: bad access detected
[   37.200144]
[   37.201647] Memory state around the buggy address:
[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc
[   37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc
[   37.228186]                                ^
[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   37.246962] ==================================================================
[   37.254394] Disabling lock debugging due to kernel taint
0+1 records in
0+1 records out
3 bytes copied, 0.335911 s, 0.0 kB/s

Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller")
Cc: stable@kernel.org
Signed-off-by: Han Xu 
Link: https://patch.msgid.link/20240911211146.3337068-1-han.xu@nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: spi-fsl-lpspi: Fix scldiv calculation

2024-08-19T03:33:50+00:00

[ Upstream commit 730bbfaf7d4890bd99e637db7767dc68cfeb24e7 ]

The effective SPI clock frequency should never exceed speed_hz
otherwise this might result in undefined behavior of the SPI device.

Currently the scldiv calculation could violate this constraint.
For the example parameters perclk_rate = 24 MHz and speed_hz = 7 MHz,
the function fsl_lpspi_set_bitrate will determine perscale = 0 and
scldiv = 1, which is a effective SPI clock of 8 MHz.

So fix this by rounding up the quotient of perclk_rate and speed_hz.
While this never change within the loop, we can pull this out.

Fixes: 5314987de5e5 ("spi: imx: add lpspi bus driver")
Signed-off-by: Stefan Wahren 
Link: https://patch.msgid.link/20240804113611.83613-1-wahrenst@gmx.net
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: fsl-lpspi: remove unneeded array

2024-08-19T03:33:50+00:00

[ Upstream commit 2fa98705a9289c758b6154a22174aa8d4041a285 ]

- replace the array with the shift operation
- remove the extra comparing operation.

Signed-off-by: Oleksandr Suvorov 
Link: https://lore.kernel.org/r/20200220141143.3902922-2-oleksandr.suvorov@toradex.com
Signed-off-by: Mark Brown 
Stable-dep-of: 730bbfaf7d48 ("spi: spi-fsl-lpspi: Fix scldiv calculation")
Signed-off-by: Sasha Levin

spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices

2024-07-27T08:38:32+00:00

[ Upstream commit ce1dac560a74220f2e53845ec0723b562288aed4 ]

While in commit 2dd33f9cec90 ("spi: imx: support DMA for imx35") it was
claimed that DMA works on i.MX25, i.MX31 and i.MX35 the respective
device trees don't add DMA channels. The Reference manuals of i.MX31 and
i.MX25 also don't mention the CSPI core being DMA capable. (I didn't
check the others.)

Since commit e267a5b3ec59 ("spi: spi-imx: Use dev_err_probe for failed
DMA channel requests") this results in an error message

	spi_imx 43fa4000.spi: error -ENODEV: can't get the TX DMA channel!

during boot. However that isn't fatal and the driver gets loaded just
fine, just without using DMA.

Signed-off-by: Uwe Kleine-König 
Link: https://patch.msgid.link/20240508095610.2146640-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

spi: stm32: Don't warn about spurious interrupts

2024-06-16T11:28:48+00:00

[ Upstream commit 95d7c452a26564ef0c427f2806761b857106d8c4 ]

The dev_warn to notify about a spurious interrupt was introduced with
the reasoning that these are unexpected. However spurious interrupts
tend to trigger continously and the error message on the serial console
prevents that the core's detection of spurious interrupts kicks in
(which disables the irq) and just floods the console.

Fixes: c64e7efe46b7 ("spi: stm32: make spurious and overrun interrupts visible")
Signed-off-by: Uwe Kleine-König 
Link: https://msgid.link/r/20240521105241.62400-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin